[{"content":" Vlad K. U.S. Citizen | Penn State Cybersecurity Analytics \u0026 Operations, Cum Laude | ServiceNow SecOps | Vulnerability Response | OT/ICS Security Cybersecurity portfolio focused on ServiceNow SecOps, vulnerability management, security operations, risk analysis, incident response, malware analysis, forensics, and OT/ICS security. Start Here Best first click for a quick review of my background, projects, and role fit.\nReview Paths Projects Resume Credentials Contact Featured Areas ServiceNow SecOps # Vulnerability Response workflow, ownership, remediation tracking, validation, and closure.\nPrimary Focus\nIncident Response \u0026amp; Forensics # Capstone investigation work with forensic images, memory artifacts, logs, timeline building, and remediation.\nFlagship Evidence\nMalware Analysis # Static and dynamic analysis, unpacking, FLOSS, PE review, ProcMon, RegShot, IDA Pro, and Ghidra.\nReverse Engineering\nGRC, Risk \u0026amp; Privacy # Security risk management, cyber law, privacy, decision analysis, incident planning, and compliance-aware thinking.\nRisk-Aware\nOT/ICS Security # Industrial security interest focused on SCADA/PLC concepts, cyber-physical risk, availability, and recovery validation.\nSpecialty Interest\nHCI, Cloud \u0026amp; Software # User-centered design, cloud infrastructure, containers, Java/OOP, MVC, web design, and portfolio engineering.\nTechnical Foundation\n","date":"5 June 2026","externalUrl":null,"permalink":"/","section":"","summary":"","title":"","type":"page"},{"content":"","date":"5 June 2026","externalUrl":null,"permalink":"/tags/abstract-classes/","section":"Tags","summary":"","title":"Abstract Classes","type":"tags"},{"content":"","date":"5 June 2026","externalUrl":null,"permalink":"/tags/accessibility/","section":"Tags","summary":"","title":"Accessibility","type":"tags"},{"content":"","date":"5 June 2026","externalUrl":null,"permalink":"/tags/acpa/","section":"Tags","summary":"","title":"ACPA","type":"tags"},{"content":"","date":"5 June 2026","externalUrl":null,"permalink":"/tags/active-directory/","section":"Tags","summary":"","title":"Active Directory","type":"tags"},{"content":"","date":"5 June 2026","externalUrl":null,"permalink":"/tags/ai-forensics/","section":"Tags","summary":"","title":"AI Forensics","type":"tags"},{"content":"","date":"5 June 2026","externalUrl":null,"permalink":"/tags/analytic-confidence/","section":"Tags","summary":"","title":"Analytic Confidence","type":"tags"},{"content":"","date":"5 June 2026","externalUrl":null,"permalink":"/tags/application-development/","section":"Tags","summary":"","title":"Application Development","type":"tags"},{"content":"","date":"5 June 2026","externalUrl":null,"permalink":"/tags/arraylist/","section":"Tags","summary":"","title":"ArrayList","type":"tags"},{"content":"","date":"5 June 2026","externalUrl":null,"permalink":"/tags/arrays/","section":"Tags","summary":"","title":"Arrays","type":"tags"},{"content":"","date":"5 June 2026","externalUrl":null,"permalink":"/tags/behavioral-decision-making/","section":"Tags","summary":"","title":"Behavioral Decision-Making","type":"tags"},{"content":"","date":"5 June 2026","externalUrl":null,"permalink":"/tags/business-continuity/","section":"Tags","summary":"","title":"Business Continuity","type":"tags"},{"content":"","date":"5 June 2026","externalUrl":null,"permalink":"/tags/capstone/","section":"Tags","summary":"","title":"Capstone","type":"tags"},{"content":"","date":"5 June 2026","externalUrl":null,"permalink":"/categories/","section":"Categories","summary":"","title":"Categories","type":"categories"},{"content":"","date":"5 June 2026","externalUrl":null,"permalink":"/tags/cfaa/","section":"Tags","summary":"","title":"CFAA","type":"tags"},{"content":"","date":"5 June 2026","externalUrl":null,"permalink":"/tags/cloud-architecture/","section":"Tags","summary":"","title":"Cloud Architecture","type":"tags"},{"content":"","date":"5 June 2026","externalUrl":null,"permalink":"/tags/cloud-security/","section":"Tags","summary":"","title":"Cloud Security","type":"tags"},{"content":"","date":"5 June 2026","externalUrl":null,"permalink":"/tags/college-of-ist/","section":"Tags","summary":"","title":"College of IST","type":"tags"},{"content":"","date":"5 June 2026","externalUrl":null,"permalink":"/tags/communication-planning/","section":"Tags","summary":"","title":"Communication Planning","type":"tags"},{"content":"","date":"5 June 2026","externalUrl":null,"permalink":"/tags/compliance/","section":"Tags","summary":"","title":"Compliance","type":"tags"},{"content":"","date":"5 June 2026","externalUrl":null,"permalink":"/tags/compromised-credentials/","section":"Tags","summary":"","title":"Compromised Credentials","type":"tags"},{"content":"","date":"5 June 2026","externalUrl":null,"permalink":"/tags/computer-forensics/","section":"Tags","summary":"","title":"Computer Forensics","type":"tags"},{"content":"","date":"5 June 2026","externalUrl":null,"permalink":"/tags/contingency-planning/","section":"Tags","summary":"","title":"Contingency Planning","type":"tags"},{"content":"","date":"5 June 2026","externalUrl":null,"permalink":"/tags/csirt/","section":"Tags","summary":"","title":"CSIRT","type":"tags"},{"content":" Incident Response / DR / BC Case Study\nThis portfolio-safe case study summarizes selected CYBER 342W Cyber Incident Handling and Response work focused on incident response planning, NIST 800-61 concepts, CSIRT structure, incident communication, containment, eradication, recovery, post-incident activity, disaster recovery, business continuity, and cybersecurity writing.\nCourse CYBER 342W Project Type Incident Response Planning / Writing-Intensive Case Study Framework Angle NIST 800-61 Incident Response Lifecycle Focus Preparation · Detection · Containment · Recovery · Lessons Learned Supporting Themes DR/BC · Communication · CSIRT · IR Policy · Data Breach Response Publishing Level Portfolio-Safe / Redacted / No Raw Submissions Published Overview # CYBER 342W focused on cyber incident handling and response from both a technical and professional communication perspective.\nThe strongest portfolio angle for this course is incident response planning and disaster recovery readiness. The work included a group incident response plan for a simulated enterprise environment, NIST 800-61-style lifecycle planning, CSIRT role definition, communication strategy, policy development, evidence handling, containment and recovery planning, post-incident lessons learned, business continuity planning, and individual writing assignments on cybersecurity incidents and response recommendations.\nThis page is intentionally written as a portfolio-safe summary. It does not publish raw academic submissions, full group reports, private student identifiers, complete presentation content, internal course materials, or step-by-step incident procedures.\nWhy This Project Matters # Incident response is not only a technical workflow. It is also an organizational discipline.\nA strong incident response plan requires:\nclear roles and responsibilities defined incident declaration authority communication paths evidence-handling expectations escalation criteria legal and HR coordination coordination with external parties backup and recovery planning documentation standards incident prioritization post-incident lessons learned executive-level reporting CYBER 342W helped connect technical incident response with policy, governance, documentation, and business continuity.\nThis makes the course useful evidence for cybersecurity analyst, ServiceNow SecOps, vulnerability management, GRC-aware security operations, and incident response support roles.\nPortfolio-Safe Publishing Approach # Security and privacy note: This case study summarizes incident response planning and writing-intensive coursework without publishing raw group submissions, private student details, full academic reports, private diagrams, exact team member information, or complete incident response procedures.\nThis page excludes:\nraw group submissions full presentations private student identifiers complete organizational diagrams complete incident response policy text full academic answers internal course materials exact personal contact details full source documents step-by-step operational procedures Instead, it presents:\nincident response themes planning structure portfolio-safe summaries framework alignment writing and communication lessons disaster recovery and business continuity concepts cybersecurity policy and response lessons Major Workstreams # Incident Response Plan # Developed a structured incident response plan for a simulated enterprise environment, including roles, lifecycle phases, communication expectations, policy considerations, and response responsibilities.\nIR Planning\nNIST 800-61 Lifecycle # Aligned the incident response plan to preparation, detection and analysis, containment, eradication, recovery, and post-incident activity.\nNIST 800-61\nCSIRT Structure # Defined incident response governance, CSIRT roles, CISO authority, internal coordination, escalation paths, and responsibilities during an incident.\nCSIRT\nCommunication Strategy # Addressed internal and external communication, legal review, HR coordination, law enforcement escalation, external incident response support, and need-to-know disclosure.\nCommunication\nDisaster Recovery / Business Continuity # Explored disaster preparedness, employee check-in systems, alert rosters, power outage planning, secondary site coordination, and business continuity documentation.\nDR / BC\nCybersecurity Writing # Completed writing-intensive assignments translating cyber incidents, DNS hijacking, data breach prevention, IT auditing, and disaster recovery planning into professional recommendations.\nWriting Intensive\nIncident Response Lifecycle Evidence # 1 Preparation # Planned resources, tools, communication lists, security controls, backup tools, encryption software, network diagrams, SIEM support, endpoint protection, authentication controls, and incident response documentation.\nPreparation\n2 Detection and Analysis # Focused on identifying precursors and indicators, reviewing logs, receiving outside reports, prioritizing incident handling, safeguarding incident data, correlating events, and understanding normal network behavior.\nDetection\n3 Containment # Planned containment strategy around limiting loss, preventing exfiltration, reducing operational disruption, preserving evidence, and coordinating response activity.\nContainment\n4 Eradication # Outlined the need to remove the threat, eliminate malicious activity, address root causes, and support remediation after the scope and source of the incident are understood.\nEradication\n5 Recovery # Connected recovery to restoration of critical services, validation of restored systems, backup strategy, operational continuity, and stakeholder communication.\nRecovery\n6 Post-Incident Activity # Addressed lessons learned, process review, cost analysis, improvement planning, control updates, and preparation for future incidents.\nLessons Learned\nGroup Incident Response Planning # The main group project developed a formal incident response plan for a simulated enterprise organization.\nThe plan included:\nincident response capability definition incident response goals preparation activities identification and detection process containment strategy eradication planning recovery planning post-incident activity cyber incident response governance team CSIRT responsibilities CISO incident declaration authority communication plan legal and HR coordination external incident response vendor involvement law enforcement escalation considerations evidence handling expectations information sharing considerations automation and coordination concepts The project reinforced that incident response is a coordinated business process, not only a technical investigation.\nCSIRT and Governance Concepts # The incident response plan included defined responsibility areas for governance and response teams.\nKey concepts included:\nincident response governance oversight CISO-led incident declaration cybersecurity team response responsibilities network operations involvement IT service involvement communications coordination legal and HR involvement contracted incident response vendor coordination incident severity and risk classification authority for monitoring and retrieving relevant organizational data during investigations need-to-know communication principles external disclosure control This supports a governance-aware cybersecurity perspective because response teams need clear authority before an incident occurs.\nDetection and Analysis Concepts # The project emphasized detection and analysis as a structured process.\nAreas included:\nprecursors and indicators outside-party incident reporting logging and auditing procedures information recording safeguarding incident data incident prioritization network and system profiling normal behavior baselining log retention event correlation host clock synchronization knowledge base development This maps closely to security operations because analysts must determine whether activity is normal, suspicious, or confirmed incident behavior.\nContainment, Eradication, and Recovery Concepts # The plan addressed containment, eradication, and recovery from both technical and operational perspectives.\nThemes included:\ncontainment strategy evidence gathering and handling volatile data capture forensic disk imaging hot and cold backup considerations system restoration service recovery remediation validation reducing disruption of services preventing additional data loss removing threat activity restoring critical computing services This is relevant to incident response and ServiceNow SecOps because both require documented remediation, clear ownership, validation, and closure.\nCommunication and Information Sharing # The project included a communication strategy for internal and external coordination.\nTopics included:\nCISO-led communication during incident confirmation internal need-to-know communication legal review before external coordination HR coordination for internal threats law enforcement escalation external incident response vendor support notification considerations for affected individuals information sharing agreements automation of information sharing relevance, timeliness, and security of shared information avoiding unnecessary disclosure during active incidents This reinforced that incident communication must be deliberate, controlled, legally reviewed, and tied to the severity of the incident.\nDisaster Recovery and Business Continuity Evidence # Individual assignments and bonus work supported disaster recovery and business continuity planning.\nTopics included:\ndisaster preparedness business continuity planning disaster recovery planning employee alert rosters employee check-in systems sequential and hierarchical notification methods power outage planning communication infrastructure failures use of secondary coordination sites evacuation and shelter-in-place considerations backup records emergency employee alert lists personal emergency readiness go-kit planning continuity needs for computing and connectivity This strengthens the course as a DR/BC evidence point, especially for roles where cyber incident response intersects with operational resilience.\nIndividual Writing Assignment Themes # Assignment Theme Portfolio-Safe Summary Professional Angle Data Breach Prevention Analyzed a major genealogy-platform breach scenario and recommended stronger password storage, hashing practices, two-factor authentication, forensic review, penetration testing, and future incident mitigation. Breach Response DNS Hijacking Response Analyzed DNS hijacking risk and recommended DNS record audits, password resets, MFA, certificate transparency log monitoring, and stronger DNS infrastructure governance. DNS Security IT Auditor Toolkit Outlined tools and certifications relevant to an IT auditor role, including data analysis tools, log analytics, SIEM, access control, business systems, and audit-focused certifications. Audit / GRC DR/BC for Home Connected disaster recovery and business continuity concepts to personal emergency preparedness, life safety, computing needs, connectivity planning, fallback communications, and continuity thinking. Resilience Alert Rosters and Check-In Systems Reviewed employee alert rosters, check-in systems, communication challenges during power outages, lack of communication infrastructure, and secondary site coordination. Continuity Planning Tool and Control Concepts Referenced # The course work referenced or evaluated several tools, platforms, and security controls in an incident response context:\nTool / Control Area Purpose in Incident Response Planning Category SIEM and Log Analytics Used conceptually for intrusion tracking, log review, event correlation, alerting, and investigation support. Detection Endpoint Protection Referenced for endpoint lockdown, monitoring, malicious file detection, USB monitoring, and endpoint visibility. Endpoint Security Firewalls and Network Controls Referenced for traffic control, device groups, network zones, whitelisting, blacklisting, VPN support, and network segmentation thinking. Network Security Authentication Controls Addressed credential management, MFA, Active Directory integration, and access-control hardening. Access Control Backup and Recovery Tools Referenced in the context of business continuity, system restoration, and resilience after cyber incidents or outages. Recovery Ticketing and Collaboration Referenced for incident tracking, task coordination, documentation, and response communication. Coordination Capability-to-Evidence Map # Capability Evidence from CYBER 342W Status Incident Response Planning Developed a structured incident response plan aligned to preparation, detection, containment, eradication, recovery, and post-incident activity. Completed CSIRT / Governance Structure Defined response governance, CSIRT responsibilities, CISO declaration authority, communications roles, and external coordination considerations. Completed Detection and Analysis Planning Addressed indicators, precursors, event correlation, logging, auditing, network baselining, host clock synchronization, and prioritization. Completed Containment and Recovery Planning Planned containment strategy, evidence handling, volatile data capture, forensic disk imaging, service restoration, backup considerations, and remediation validation. Completed Disaster Recovery / Business Continuity Analyzed alert rosters, employee check-in systems, secondary sites, power outages, communication failures, emergency preparedness, and continuity planning. Completed Cybersecurity Writing Converted incident response, DNS hijacking, data breach, audit, and disaster recovery topics into professional writing and recommendations. Completed What I Learned # This course reinforced several lessons that matter in cybersecurity operations and consulting:\nincident response should be planned before an incident occurs response teams need defined authority and escalation paths communication failures can create incident response failures documentation is critical during detection, containment, recovery, and review legal, HR, communications, vendors, and law enforcement may all be part of an incident response process evidence handling must be planned and controlled logs, baselines, and event correlation are central to incident detection backup and recovery planning must be tested before a real incident business continuity requires people, process, facilities, and communication planning technical incidents must be translated into clear professional recommendations cybersecurity writing matters because incident response depends on clarity, precision, and stakeholder trust Professional Relevance # This project supports roles involving:\ncybersecurity analysis security operations incident response disaster recovery business continuity vulnerability management ServiceNow SecOps consulting security policy support GRC-aware cybersecurity work technical writing and security documentation stakeholder communication It also supports my ServiceNow SecOps direction because structured incident response maps well to ServiceNow security workflows: triage, assignment ownership, communication, remediation tracking, validation, closure, documentation, and post-incident review.\nDifference from CYBER 440 Capstone # CYBER 342W and CYBER 440 both relate to incident response, but they show different strengths.\nCourse Main Portfolio Angle Best Evidence Type CYBER 342W Incident response planning, NIST lifecycle, CSIRT governance, communication, DR/BC, policy, and cybersecurity writing. Planning / Policy CYBER 440 Hands-on capstone investigation involving network evidence, forensic images, memory analysis, logs, incident timeline, and remediation reporting. Forensics / Investigation Together, they show both sides of incident response: planning the response program and investigating a simulated incident.\nPortfolio-Safe Redaction Notes # This case study intentionally excludes:\nraw group submissions full presentations complete incident response plans private student identifiers private organizational diagrams exact team member details full academic answers internal course materials complete procedural steps The goal is to show planning, policy, response structure, and professional communication without publishing raw academic work.\nRelated Portfolio Areas # Incident Response # This course supports incident response readiness through planning, governance, detection, containment, recovery, and lessons learned.\nIR Planning\nDisaster Recovery / Business Continuity # The course connected cyber incidents to outage planning, communication resilience, backup strategy, emergency readiness, and continuity planning.\nDR / BC\nServiceNow SecOps # ServiceNow SecOps workflows benefit from clear incident ownership, communication, documentation, remediation tracking, validation, and closure.\nSecOps-Relevant\nGRC and Policy # The work includes policy, governance structure, external coordination, legal considerations, information sharing, and business impact thinking.\nGRC-Relevant\nNext Steps # This project can later be connected to:\na ServiceNow Security Incident Response workflow concept a disaster recovery / business continuity capability section a CSIRT role mapping page an incident communication checklist a NIST 800-61 lifecycle diagram a policy-to-workflow mapping example a ServiceNow SecOps incident response case concept For now, this page serves as the main portfolio-safe summary of my CYBER 342W Cyber Incident Handling and Response work.\n","date":"5 June 2026","externalUrl":null,"permalink":"/projects/cyber-342w-incident-response-disaster-recovery-planning/","section":"Projects","summary":"","title":"CYBER 342W: Incident Response, Disaster Recovery \u0026 Business Continuity Planning","type":"projects"},{"content":" Cybersecurity Capstone\nThis portfolio-safe case study summarizes selected CYBER 440 capstone work involving a simulated organizational compromise, phishing-led malware infection, forensic image analysis, network traffic review, memory analysis, log analysis, incident timeline development, impact assessment, and remediation planning.\nCourse CYBER 440 Project Type Cybersecurity Capstone / Incident Response Case Study Focus IR · Digital Forensics · Network Analysis · Memory Analysis · Logs Scenario Simulated Municipal Organization Compromise Publishing Level Portfolio-Safe / Redacted / No Raw Evidence Files Professional Angle Security Operations, Incident Response, and Forensic Reporting Overview # CYBER 440 was a cybersecurity capstone course focused on investigating a simulated organizational compromise using multiple evidence sources and analyst workflows.\nThe project required connecting evidence from:\nnetwork captures forensic system images Windows event logs memory artifacts suspicious processes user activity email-based compromise indicators ransomware-style artifacts malware-related findings timeline reconstruction business impact analysis remediation recommendations This page presents the work as a portfolio-safe case study. It does not publish raw evidence files, forensic images, full screenshots, private academic submissions, user account details, exact hashes, or sensitive artifacts.\nWhy This Project Matters # This capstone is valuable because it shows a more complete cybersecurity investigation workflow than a single isolated lab.\nA real investigation requires analysts to combine multiple views of the same incident:\nwhat happened on the network what happened on endpoints what changed on disk what was visible in memory what logs support the timeline which systems and users were affected which attack vector was most likely what operational impact occurred what should be done next The project also required communication. Findings had to be converted into a clear status report and final report that could explain the incident, its impact, and recommended remediation steps.\nScenario Summary # The capstone scenario involved a simulated compromise affecting multiple organizational systems.\nThe investigation identified a phishing-led attack path involving a malicious file disguised as a PDF attachment. The suspected infection chain led to malware execution, suspicious processes, remote-access risk, file deletion, ransom-note artifacts, exposed credentials, failed authentication events, and operational disruption.\nThe strongest working theory was that a phishing email introduced malware into the environment, after which the compromise affected multiple systems and required coordinated incident response.\nPortfolio-Safe Redaction Approach # Security note: This case study intentionally avoids publishing raw forensic images, packet captures, screenshots, hashes, complete usernames, full email artifacts, private academic files, or step-by-step evidence extraction details.\nThis page excludes:\nraw forensic images packet capture files memory dumps full screenshots complete raw logs exact hashes private student identifiers full team submissions complete academic answers sensitive simulated evidence artifacts step-by-step replication instructions Instead, it summarizes:\ninvestigation workflow evidence categories technical themes analyst reasoning incident timeline concepts impact assessment remediation thinking professional lessons learned Investigation Workflow # 1 Initial Scope and Evidence Review # Reviewed available evidence sources and identified major analysis tracks: network traffic, forensic images, memory artifacts, and Windows/event log data.\nScope\n2 Network Analysis # Reviewed network captures to identify communication timelines, suspicious email activity, credential exposure concerns, affected systems, and event sequencing.\nNetwork Forensics\n3 Forensic Image Analysis # Analyzed Windows system images, reviewed user directories, downloads, desktop artifacts, application history, suspicious files, and system folders relevant to compromise investigation.\nDisk Forensics\n4 Memory Analysis # Reviewed memory-related findings to identify suspicious processes, unknown parent-child process relationships, possible hands-on-keyboard activity, and incomplete or obfuscated process metadata.\nMemory Analysis\n5 Log Analysis # Analyzed Windows and server log evidence for failed authentication, anonymous access attempts, service state changes, PTR registration issues, audit failures, and access-related anomalies.\nLog Analysis\n6 Impact and Remediation # Translated technical findings into operational impact, risk exposure, containment priorities, restoration recommendations, and future prevention steps.\nRemediation\nEvidence Areas # Phishing-Led Compromise # The investigation identified a phishing-style email with a malicious attachment disguised as a PDF as the likely initial compromise path.\nInitial Access\nMalware Execution # The analysis connected the suspicious file activity to malware execution and remote-access risk, including backdoor-style behavior and potential credential exposure.\nMalware Investigation\nForensic Image Review # Forensic images were reviewed for user directories, desktop artifacts, suspicious downloads, temp folders, application history, event logs, and evidence of encrypted or suspicious files.\nDisk Forensics\nMemory Artifacts # Memory analysis identified suspicious processes, unusual process relationships, missing or incomplete metadata, and indicators that required further investigation.\nMemory Analysis\nWindows and Server Logs # Log review focused on authentication failures, service state changes, PTR registration issues, anonymous access attempts, and server-management anomalies.\nLog Analysis\nIncident Reporting # Findings were summarized into status reports and a final incident report with executive summary, attack vector analysis, impact assessment, and remediation recommendations.\nReporting\nNetwork Analysis Themes # Network analysis focused on understanding communication patterns and timeline evidence.\nKey activities included:\nreviewing network capture time ranges identifying email-related activity supporting the incident timeline looking for suspicious communication patterns connecting network evidence to endpoint findings identifying potential credential exposure concerns mapping communications between affected users and systems The network evidence helped support the conclusion that the incident was connected to a malicious file delivered through email rather than a simple port manipulation issue.\nForensic Image Analysis Themes # Forensic image analysis focused on endpoint artifacts.\nAreas reviewed included:\nuser profile directories Documents, Downloads, Desktop, and Pictures folders Windows system folders temporary files suspicious executables browser and application history encrypted or suspicious files Windows event log artifacts hash verification to confirm image integrity This portion of the work helped connect user activity, suspicious files, ransomware-style artifacts, and endpoint-level evidence to the broader incident timeline.\nMemory Analysis Themes # Memory analysis focused on volatile artifacts and running processes.\nThe investigation considered:\nsuspicious process names unknown or missing process metadata suspicious parent-child process relationships command-line visibility process timing possible hands-on-keyboard indicators potential process obfuscation malicious or unknown executable behavior This reinforced the importance of memory analysis in incident response because disk evidence alone may not fully explain what was happening at runtime.\nLog Analysis Themes # Log analysis focused on Windows and server events.\nThe work included review of:\nfailed authentication anonymous access attempts service start/stop behavior PTR registration errors audit failures network share access attempts server-management errors suspicious timing correlations affected Windows and Windows Server systems Log evidence helped translate individual artifacts into a broader operational picture.\nImpact Assessment # The incident created risk across several dimensions:\nImpact Area Observed or Inferred Risk Severity Confidentiality Potential credential exposure, sensitive data access, and remote-access malware risk. High Integrity Suspicious file changes, ransom-note artifacts, deleted files, and concerns around audit failures or altered system behavior. High Availability Service disruptions, system instability, file loss, and operational delays affecting IT and business processes. High Reputation and Governance Potential stakeholder confidence issues, policy concerns, incident response maturity concerns, and possible regulatory or compliance exposure. High Remediation Recommendations # The capstone response emphasized both immediate containment and long-term security improvement.\nRecommended actions included:\nisolate affected systems preserve evidence for forensic review conduct complete forensic analysis identify all compromised accounts and processes remove malware and unauthorized processes reset affected passwords strengthen authentication improve network monitoring update security policies conduct security awareness training perform recurring vulnerability assessments update the incident response plan document lessons learned communicate clearly with stakeholders during recovery These recommendations are useful because they connect technical findings to operational decision-making.\nCapability-to-Evidence Map # Capability Evidence from CYBER 440 Status Incident Response Investigated phishing-led compromise, identified affected systems, built incident timeline, summarized impact, and recommended containment and recovery actions. Completed Network Forensics Reviewed network captures, communication timeline, email activity, packet-scale evidence, and suspicious access concerns. Completed Digital Forensics Analyzed Windows forensic images, user directories, suspicious files, downloads, desktop artifacts, temp folders, application history, and event logs. Completed Memory Analysis Reviewed suspicious processes, process metadata gaps, process relationships, and possible runtime indicators of compromise. Completed Log Analysis Reviewed authentication failures, anonymous access attempts, service state changes, PTR issues, audit failures, and server-side anomalies. Completed Executive Reporting Converted technical findings into executive summary, attack vector analysis, impact analysis, remediation planning, and final incident reporting. Completed What I Learned # This capstone reinforced several important cybersecurity lessons:\nincident response requires multiple evidence sources phishing remains one of the most effective initial access vectors endpoint evidence and network evidence must be correlated forensic image analysis helps preserve and reconstruct user/system behavior memory analysis can expose runtime artifacts that disk analysis may miss logs are essential for timeline reconstruction and access review suspicious processes need context from disk, memory, logs, and network data impact analysis should include confidentiality, integrity, availability, operations, reputation, and governance remediation must include both immediate containment and long-term prevention final reporting matters because technical findings must be understandable to decision-makers Professional Relevance # This project supports roles involving:\ncybersecurity analysis security operations incident response digital forensics vulnerability management malware investigation threat analysis security consulting governance-aware security reporting It also supports my ServiceNow SecOps direction because incident response and Vulnerability Response both require structured triage, ownership, remediation tracking, validation, documentation, and stakeholder communication.\nPortfolio-Safe Redaction Notes # This case study intentionally excludes:\nraw forensic images raw packet captures memory dumps private screenshots complete raw logs exact hashes private user details full academic submissions full team report content step-by-step evidence extraction details The goal is to show investigation workflow, reasoning, and security communication without exposing raw evidence or sensitive academic materials.\nRelated Portfolio Areas # Security Operations # This capstone supports SOC-style work through triage, evidence review, timeline reconstruction, and escalation-oriented reporting.\nSOC-Relevant\nDigital Forensics # The project included forensic image review, endpoint artifact analysis, application history review, suspicious files, and event log review.\nForensics\nIncident Response # The project required identifying compromise mechanism, affected systems, impact, and immediate/long-term remediation steps.\nIncident Response\nServiceNow SecOps # The workflow maps naturally to SecOps concepts such as incident triage, ownership, remediation tracking, documentation, and validation.\nSecOps-Relevant\nNext Steps # This capstone could later be expanded with:\na sanitized incident timeline diagram a portfolio-safe IR lifecycle diagram a detection-to-remediation workflow map a ServiceNow Security Incident Response mapping concept a lessons-learned table a mock executive incident report template For now, this page serves as the main portfolio-safe summary of my CYBER 440 cybersecurity capstone work.\n","date":"5 June 2026","externalUrl":null,"permalink":"/projects/cyber-440-cybersecurity-capstone-incident-response-forensics/","section":"Projects","summary":"","title":"CYBER 440: Cybersecurity Capstone Incident Response \u0026 Forensics","type":"projects"},{"content":"","date":"5 June 2026","externalUrl":null,"permalink":"/tags/cyber-forensics/","section":"Tags","summary":"","title":"Cyber Forensics","type":"tags"},{"content":"","date":"5 June 2026","externalUrl":null,"permalink":"/tags/cyber-hygiene/","section":"Tags","summary":"","title":"Cyber Hygiene","type":"tags"},{"content":"","date":"5 June 2026","externalUrl":null,"permalink":"/tags/cyber-law/","section":"Tags","summary":"","title":"Cyber Law","type":"tags"},{"content":"","date":"5 June 2026","externalUrl":null,"permalink":"/tags/cybersecurity/","section":"Tags","summary":"","title":"Cybersecurity","type":"tags"},{"content":"","date":"5 June 2026","externalUrl":null,"permalink":"/tags/cybersecurity-policy/","section":"Tags","summary":"","title":"Cybersecurity Policy","type":"tags"},{"content":"","date":"5 June 2026","externalUrl":null,"permalink":"/tags/cybersecurity-writing/","section":"Tags","summary":"","title":"Cybersecurity Writing","type":"tags"},{"content":"","date":"5 June 2026","externalUrl":null,"permalink":"/tags/data-carving/","section":"Tags","summary":"","title":"Data Carving","type":"tags"},{"content":"","date":"5 June 2026","externalUrl":null,"permalink":"/tags/data-exfiltration/","section":"Tags","summary":"","title":"Data Exfiltration","type":"tags"},{"content":"","date":"5 June 2026","externalUrl":null,"permalink":"/tags/decision-matrix/","section":"Tags","summary":"","title":"Decision Matrix","type":"tags"},{"content":"","date":"5 June 2026","externalUrl":null,"permalink":"/tags/decision-theory/","section":"Tags","summary":"","title":"Decision Theory","type":"tags"},{"content":"","date":"5 June 2026","externalUrl":null,"permalink":"/tags/decision-trees/","section":"Tags","summary":"","title":"Decision Trees","type":"tags"},{"content":"","date":"5 June 2026","externalUrl":null,"permalink":"/tags/digital-forensics/","section":"Tags","summary":"","title":"Digital Forensics","type":"tags"},{"content":"","date":"5 June 2026","externalUrl":null,"permalink":"/tags/digital-governance/","section":"Tags","summary":"","title":"Digital Governance","type":"tags"},{"content":"","date":"5 June 2026","externalUrl":null,"permalink":"/tags/disaster-recovery/","section":"Tags","summary":"","title":"Disaster Recovery","type":"tags"},{"content":"","date":"5 June 2026","externalUrl":null,"permalink":"/tags/docker/","section":"Tags","summary":"","title":"Docker","type":"tags"},{"content":"","date":"5 June 2026","externalUrl":null,"permalink":"/tags/encapsulation/","section":"Tags","summary":"","title":"Encapsulation","type":"tags"},{"content":"","date":"5 June 2026","externalUrl":null,"permalink":"/tags/enigma-glass/","section":"Tags","summary":"","title":"Enigma Glass","type":"tags"},{"content":"","date":"5 June 2026","externalUrl":null,"permalink":"/tags/expected-value/","section":"Tags","summary":"","title":"Expected Value","type":"tags"},{"content":"","date":"5 June 2026","externalUrl":null,"permalink":"/tags/figma/","section":"Tags","summary":"","title":"Figma","type":"tags"},{"content":"","date":"5 June 2026","externalUrl":null,"permalink":"/tags/file-system-forensics/","section":"Tags","summary":"","title":"File System Forensics","type":"tags"},{"content":"","date":"5 June 2026","externalUrl":null,"permalink":"/tags/fisa/","section":"Tags","summary":"","title":"FISA","type":"tags"},{"content":"","date":"5 June 2026","externalUrl":null,"permalink":"/tags/forensic-imaging/","section":"Tags","summary":"","title":"Forensic Imaging","type":"tags"},{"content":"","date":"5 June 2026","externalUrl":null,"permalink":"/tags/ftk-imager/","section":"Tags","summary":"","title":"FTK Imager","type":"tags"},{"content":"","date":"5 June 2026","externalUrl":null,"permalink":"/tags/grc/","section":"Tags","summary":"","title":"GRC","type":"tags"},{"content":"","date":"5 June 2026","externalUrl":null,"permalink":"/tags/group-decisions/","section":"Tags","summary":"","title":"Group Decisions","type":"tags"},{"content":"","date":"5 June 2026","externalUrl":null,"permalink":"/tags/gui/","section":"Tags","summary":"","title":"GUI","type":"tags"},{"content":"","date":"5 June 2026","externalUrl":null,"permalink":"/tags/gui-development/","section":"Tags","summary":"","title":"GUI Development","type":"tags"},{"content":"","date":"5 June 2026","externalUrl":null,"permalink":"/tags/hci/","section":"Tags","summary":"","title":"HCI","type":"tags"},{"content":"","date":"5 June 2026","externalUrl":null,"permalink":"/tags/high-fidelity-prototype/","section":"Tags","summary":"","title":"High-Fidelity Prototype","type":"tags"},{"content":"","date":"5 June 2026","externalUrl":null,"permalink":"/tags/hyper-v/","section":"Tags","summary":"","title":"Hyper-V","type":"tags"},{"content":"","date":"5 June 2026","externalUrl":null,"permalink":"/tags/incident-response/","section":"Tags","summary":"","title":"Incident Response","type":"tags"},{"content":"","date":"5 June 2026","externalUrl":null,"permalink":"/tags/information-security/","section":"Tags","summary":"","title":"Information Security","type":"tags"},{"content":"","date":"5 June 2026","externalUrl":null,"permalink":"/tags/inheritance/","section":"Tags","summary":"","title":"Inheritance","type":"tags"},{"content":"","date":"5 June 2026","externalUrl":null,"permalink":"/tags/instructional-design/","section":"Tags","summary":"","title":"Instructional Design","type":"tags"},{"content":"","date":"5 June 2026","externalUrl":null,"permalink":"/tags/interface-design/","section":"Tags","summary":"","title":"Interface Design","type":"tags"},{"content":"","date":"5 June 2026","externalUrl":null,"permalink":"/tags/interfaces/","section":"Tags","summary":"","title":"Interfaces","type":"tags"},{"content":"","date":"5 June 2026","externalUrl":null,"permalink":"/tags/internship/","section":"Tags","summary":"","title":"Internship","type":"tags"},{"content":"","date":"5 June 2026","externalUrl":null,"permalink":"/tags/iot-forensics/","section":"Tags","summary":"","title":"IoT Forensics","type":"tags"},{"content":"","date":"5 June 2026","externalUrl":null,"permalink":"/tags/iso-27000/","section":"Tags","summary":"","title":"ISO 27000","type":"tags"},{"content":" Software Foundations Case Study\nThis portfolio-safe case study summarizes selected IST 240 Introduction to Computer Languages lab work focused on introductory Java programming, class design, object-oriented programming, constructors, methods, encapsulation, inheritance, abstract classes, arrays, ArrayLists, search logic, and model/data separation.\nCourse IST 240 Project Type Introductory Java Lab Progression Focus Java · OOP · Classes · Inheritance · Collections Concepts Constructors · Getters/Setters · toString · Arrays · ArrayLists Publishing Level Portfolio-Safe / No Raw Source Published Professional Angle Programming Foundations for Cybersecurity and Automation Overview # IST 240 introduced computer languages and programming fundamentals through a sequence of Java labs.\nThe lab progression started with a simple ZipCode class and gradually expanded into a small object-oriented model involving addresses, people, players, sports-specific subclasses, arrays, ArrayList usage, rating calculations, search methods, and a separate model/data class.\nThis page presents the work as a portfolio-safe summary. It does not publish raw source code, complete assignments, private academic materials, or full lab submissions.\nThe strongest portfolio angle is programming foundation. While this is not an advanced cybersecurity project, it supports the technical base behind later work in data structures, software engineering, scripting, security automation, malware analysis, and cybersecurity tooling.\nWhy This Project Matters # Cybersecurity professionals benefit from understanding how software is structured.\nEven when a role is not primarily software development, programming foundations help with:\nreading code writing automation scripts understanding object models parsing structured data debugging logic understanding application behavior reviewing software security issues communicating with developers building small tools understanding how data moves through classes and methods IST 240 helped build that foundation through repeated Java practice and incremental lab development.\nPortfolio-Safe Publishing Approach # Security and academic integrity note: This case study summarizes introductory Java lab work without publishing raw source code, complete lab solutions, private course materials, or full academic submissions.\nThis page excludes:\nraw source code full lab submissions complete project files private course instructions private academic records complete assignment answers copy-paste-ready solutions Instead, it presents:\nprogramming concepts practiced class design progression portfolio-safe summaries lessons learned professional relevance how the course supports later cybersecurity work Lab Progression Summary # Lab Stage Portfolio-Safe Summary Concept Zip Code Formatting Built an introductory Java class for ZIP code representation, including five-digit and plus-four formatting behavior. Class Basics Display and String Logic Expanded class behavior with output methods and substring-based display logic for prefix and area-style ZIP code components. Methods Address Modeling Added an Address class with number, street name, street type, state, PO box, and ZipCode object composition. Composition Encapsulation Refined classes using private fields, getters, setters, constructor overloads, and controlled state updates. Encapsulation Person and Player Models Introduced Person and Player classes to model shared attributes such as name, address, number, sport, and games played. OOP Modeling Inheritance Created sports-specific subclasses such as FootballPlayer and SoccerPlayer to extend the shared Player model with specialized attributes and rating logic. Inheritance Abstract Classes Used an abstract Player class to represent shared behavior while allowing child classes to implement sport-specific details. Abstraction Arrays and Lists Practiced storing player objects in arrays and ArrayLists, then iterating through records to find values, compare ratings, and search names. Collections Model Data Class Separated sample data and search logic into a ModelData class, making the main application cleaner and more organized. Separation of Concerns Major Concepts Practiced # Java Class Design # The labs progressed from a simple class into multiple related classes with fields, constructors, methods, and formatted output behavior.\nJava Basics\nEncapsulation # The work used private fields, getter and setter methods, constructor overloads, and controlled object state management.\nEncapsulation\nObject Composition # Address objects used ZipCode objects, showing how one class can contain and coordinate with another class.\nComposition\nInheritance # The Player model expanded into specialized FootballPlayer and SoccerPlayer classes, showing class hierarchy and shared behavior reuse.\nInheritance\nAbstract Classes # The Player class became an abstract parent model, allowing common fields and behavior while supporting specialized subclasses.\nAbstraction\nCollections and Search Logic # The later labs used arrays and ArrayLists to store objects, loop through records, find highest values, and search by exact or partial name.\nArrays / ArrayList\nTechnical Workflow # 1 Build a Simple Class # Started with a ZipCode class and practiced constructor behavior, string formatting, and output methods.\nClass Basics\n2 Add Object Composition # Expanded the model with Address objects that contained ZipCode objects and represented structured address data.\nComposition\n3 Encapsulate State # Refined object fields using getters, setters, private variables, and constructor overloads to control data access.\nEncapsulation\n4 Build an Inheritance Hierarchy # Added Person, Player, FootballPlayer, and SoccerPlayer classes to model shared and specialized behavior.\nInheritance\n5 Use Arrays and Collections # Stored player objects in arrays and ArrayLists, then iterated through the data to search, compare, and calculate ratings.\nCollections\n6 Separate Model Data # Moved sample data and search functions into a ModelData class, improving organization and separating application logic from data setup.\nModel Layer\nObject Model Summary # The later labs developed a small object model around people, addresses, and players.\nClass / Component Purpose Concept ZipCode Represented five-digit and plus-four ZIP code formatting and basic display behavior. Formatting Address Modeled address components and used ZipCode as a composed object. Composition Person Represented shared person-level attributes such as name and address. Base Model Player Represented shared player attributes such as number, sport, and games played; later used as an abstract parent class. Abstraction FootballPlayer Extended Player with football-specific fields such as yards and minutes played, plus rating behavior. Subclass SoccerPlayer Extended Player with soccer-specific fields such as goals and yellow cards, plus rating behavior. Subclass ModelData Loaded sample player records and supported search, rating comparison, and data retrieval methods. Model Layer Programming Skills Demonstrated # Skill Evidence from IST 240 Status Java Syntax and Structure Used Java classes, main methods, object creation, method calls, fields, constructors, and formatted output. Completed Constructors and Overloading Used default constructors and parameterized constructors to initialize objects in different ways. Completed Getter and Setter Methods Practiced encapsulation by controlling access to private fields through accessor and mutator methods. Completed String Handling Used string formatting, substring logic, conditional display behavior, and custom toString methods. Completed Inheritance and Abstraction Built a Person/Player hierarchy and extended Player into sport-specific subclasses with specialized fields and rating logic. Completed Arrays and ArrayLists Stored groups of objects, iterated through collections, compared values, searched for names, and retrieved matching records. Completed Separation of Concerns Separated sample data and lookup methods into a ModelData class instead of keeping all logic inside the main application class. Completed Difference from IST 311 # IST 240 and IST 311 both support software foundations, but they represent different levels of maturity.\nCourse Main Portfolio Angle Best Evidence Type IST 240 Introductory Java programming, object-oriented basics, class design, constructors, methods, inheritance, arrays, and ArrayLists. Programming Foundations IST 311 More advanced Java, data structures, object-oriented design, software engineering foundations, Big-O, testing, debugging, UML/CRC, and Git workflow. Software Engineering Together, they show progression from introductory programming to more structured software engineering and data-structure work.\nCybersecurity Relevance # This project supports cybersecurity work indirectly by building programming fluency.\nThe relevant cybersecurity value is not that this was a security lab. The value is that it supports the ability to:\nread Java code understand object-oriented program structure reason about application state understand how data models are built write small tools or scripts debug logic understand software behavior communicate with developers transition into security automation or secure software review better understand later coursework involving tools, parsers, logs, malware, and data structures Programming fundamentals are part of the technical base for cybersecurity analysis and engineering.\nWhat I Learned # This course reinforced several foundational lessons:\nsmall programs become easier to manage when code is organized into classes constructors define how objects are created and initialized getter and setter methods help control access to object state toString methods make objects easier to inspect and debug inheritance helps reduce duplicated behavior across related classes abstract classes can represent shared concepts while leaving details to subclasses arrays and ArrayLists make it possible to work with groups of objects search and comparison logic are easier when data is organized consistently separating model data from application logic improves readability and maintainability introductory programming skills support later cybersecurity and software engineering work Professional Relevance # This project supports roles and tasks involving:\ncybersecurity analysis ServiceNow SecOps consulting scripting and automation foundations software troubleshooting secure software awareness data parsing log analysis preparation vulnerability management support communicating with developers understanding application behavior It also supports my ServiceNow SecOps direction because ServiceNow work often benefits from understanding object models, tables, fields, scripts, data relationships, workflow logic, and structured troubleshooting.\nPortfolio-Safe Redaction Notes # This case study intentionally excludes:\nraw Java source code complete lab solutions full project ZIP contents private course instructions private academic records complete assignment answers copy-paste-ready implementation details The goal is to show programming progression and software-foundation development without publishing raw academic work.\nRelated Portfolio Areas # Software Foundations # This work supports Java, class design, object-oriented programming, constructors, methods, collections, and model/data organization.\nProgramming Foundations\nCybersecurity Analysis # Programming fluency supports log parsing, scripting, tool usage, malware analysis foundations, and understanding how applications behave.\nCybersecurity-Relevant\nServiceNow SecOps # ServiceNow work benefits from understanding objects, fields, relationships, workflow logic, data handling, and structured troubleshooting.\nSecOps-Relevant\nIST 311 Progression # IST 240 provides the introductory foundation that later supports IST 311 software engineering and data structures work.\nAcademic Progression\nNext Steps # This project can later be connected to:\nthe software foundations capability section the IST 311 project page the academic evidence map a programming foundations review path a ServiceNow scripting-readiness note a cybersecurity automation foundations section For now, this page serves as the main portfolio-safe summary of my IST 240 introductory Java programming and object-oriented programming lab progression.\n","date":"5 June 2026","externalUrl":null,"permalink":"/projects/ist-240-introductory-java-programming-oop-labs/","section":"Projects","summary":"","title":"IST 240: Introductory Java Programming \u0026 OOP Lab Progression","type":"projects"},{"content":" Intermediate Software Foundations Case Study\nThis portfolio-safe case study summarizes selected IST 242 Intermediate \u0026amp; Object-Oriented Application Development lab work focused on Java application development, inheritance, abstract classes, interfaces, polymorphism, GUI development with Swing, validation, formatted output, application structure, and model/data separation.\nCourse IST 242 Project Type Intermediate Java / OOP Lab Collection Focus Java · OOP · Interfaces · GUI · Validation · Polymorphism Concepts Inheritance · Abstract Classes · Swing · Strategy-Style Formatting · Data Access Publishing Level Portfolio-Safe / No Raw Source Published Professional Angle Application Development Foundations for Cybersecurity and ServiceNow Work Overview # IST 242 built on introductory Java programming and moved into intermediate object-oriented application development.\nThe lab work included small Java applications covering country/population modeling, customer reward logic, employee and student inheritance, HR management inheritance, number formatting through interfaces, product lookup through an interface-backed data access layer, and a Swing-based future value calculator with input validation.\nThis page presents the work as a portfolio-safe summary. It does not publish raw Java source code, complete lab solutions, private course instructions, or full academic submissions.\nThe strongest portfolio angle is intermediate software development foundation. This course shows progression from basic Java into more structured application design, object-oriented modeling, GUI construction, interface-driven programming, and reusable validation logic.\nWhy This Project Matters # Cybersecurity work often benefits from application development knowledge.\nEven when a role is not a developer role, intermediate programming skills help with:\nreading application code understanding inheritance and polymorphism understanding interfaces and abstraction debugging application behavior recognizing separation of concerns building small tools understanding input validation reasoning about UI and data flow communicating with developers understanding how security controls fit into application workflows preparing for scripting, automation, and ServiceNow platform work IST 242 helped build those skills by moving beyond isolated classes into small applications with clearer structure and reusable components.\nPortfolio-Safe Publishing Approach # Security and academic integrity note: This case study summarizes intermediate Java lab work without publishing raw source code, complete lab solutions, private course materials, or copy-paste-ready academic submissions.\nThis page excludes:\nraw Java source code complete lab solutions full project ZIP contents private course instructions private academic records complete assignment answers copy-paste-ready implementations Instead, it presents:\napplication concepts practiced object-oriented design progression portfolio-safe summaries tools and language features used professional lessons learned relevance to cybersecurity and ServiceNow work Lab Collection Summary # Project / Lab Portfolio-Safe Summary Concept Country Population Model Created a simple Country class to represent name, population, area, and population density output. Class Modeling Customer Rewards Modeled customer reward logic involving purchases, discount thresholds, store visits, boolean tracking, and reusable methods for reward eligibility. Business Logic Person / Employee / Student Model Used an abstract Person class with Employee and Student subclasses to demonstrate inheritance, shared naming behavior, and specialized descriptions. Abstract Classes HR Management Model Built an Employee, Manager, and Executive hierarchy to practice inheritance, overridden salary behavior, department/title fields, and customized string output. Inheritance Future Value GUI Calculator Built a Swing-based GUI application for future value calculation using text fields, buttons, event handlers, layout managers, number formatting, and validation. Swing GUI Number Formatter Application Used a NumberFormatter interface with multiple formatter implementations for default, decimal-separated, accounting-style, and base-conversion output. Interfaces Product Viewer Application Built a product lookup application using Product, ProductReader, and ProductDB classes to separate product data, retrieval behavior, formatting, and console interaction. Data Access Major Concepts Practiced # Intermediate Java # The labs used Java classes, packages, constructors, methods, arrays, boolean arrays, control flow, formatting, console input, and structured application entry points.\nJava\nObject-Oriented Design # Projects modeled real-world entities such as customers, countries, people, employees, managers, executives, products, and financial calculations.\nOOP Modeling\nInheritance and Abstract Classes # The labs used inheritance hierarchies and abstract classes to represent shared behavior while supporting specialized subclasses.\nInheritance\nInterfaces and Polymorphism # The NumberFormatter and ProductReader interfaces demonstrated how code can rely on a shared contract while using multiple implementations.\nInterfaces\nSwing GUI Development # The Future Value Calculator used Java Swing components, layout managers, button events, editable and non-editable fields, and formatted output.\nGUI Development\nValidation and Formatting # The GUI calculator introduced validation logic and formatted financial output, reinforcing user input handling and safer application behavior.\nValidation\nTechnical Workflow # 1 Model Simple Domain Objects # Started with smaller object models such as Country and Customer to practice fields, constructors, methods, calculations, and output behavior.\nClass Modeling\n2 Add Business Logic # Built customer reward logic using purchase thresholds, store visit tracking, reusable methods, constants, and conditional decision-making.\nBusiness Rules\n3 Build Inheritance Hierarchies # Expanded into Person, Employee, Student, Manager, and Executive models to practice abstraction, overriding, and specialized class behavior.\nInheritance\n4 Introduce Interfaces # Used interfaces such as NumberFormatter and ProductReader to separate expected behavior from implementation details.\nInterfaces\n5 Build a GUI Application # Created a Swing-based Future Value Calculator with input fields, buttons, event handlers, layout management, calculation logic, and formatted output.\nSwing GUI\n6 Add Validation and Cleaner Structure # Separated financial calculation and validation logic from the GUI where appropriate, improving maintainability and user input handling.\nValidation\nObject-Oriented Design Evidence # Design Concept Evidence from IST 242 Status Class Design Created focused classes such as Country, Customer, Product, Employee, Manager, Executive, FinancialCalculations, and Validation. Completed Encapsulation Used private fields, getters, setters, constructors, and controlled method access to represent object state and behavior. Completed Inheritance Modeled Employee, Manager, Executive, Student, and Person relationships through parent-child class structures. Completed Abstract Classes Used an abstract Person class to define shared identity behavior while requiring child classes to provide specialized descriptions. Completed Method Overriding Overrode methods such as salary calculation, description output, and string representation to support specialized behavior. Completed Interfaces Used NumberFormatter and ProductReader interfaces to define behavior contracts and support interchangeable implementations. Completed Application Examples # Customer Rewards # The rewards application modeled purchase behavior, discount thresholds, store visit tracking, and reset logic after reward eligibility.\nBusiness Logic\nHR Management # The HR example used employee, manager, and executive classes to practice inheritance, salary behavior, department/title fields, and formatted object output.\nInheritance\nFuture Value Calculator # The GUI calculator used Swing components, button click handlers, input validation, and formatted financial output.\nGUI\nNumber Formatter # The formatter application used an interface with multiple implementations to display numbers in default, decimal, accounting, and base-converted formats.\nPolymorphism\nProduct Viewer # The product viewer used a product model and a ProductReader interface to separate data lookup from application interaction.\nData Access\nPerson / Employee / Student # The abstract Person example showed how common identity behavior can be shared while child classes provide specialized descriptions.\nAbstraction\nGUI and Validation Evidence # The Future Value Calculator is one of the strongest IST 242 artifacts because it moved beyond console-only applications.\nIt included:\nJava Swing frame setup input text fields non-editable result fields labels and buttons calculate and exit button handlers layout managers number formatting future value calculation logic input validation user-facing error prevention separation between calculation logic and interface behavior This matters because user-facing tools must handle input carefully. Even simple validation work supports better security thinking because unsafe or unvalidated input is a common source of application problems.\nInterface and Polymorphism Evidence # The Number Formatter and Product Viewer labs introduced interface-driven design.\nThe Number Formatter application used a shared interface for multiple formatting strategies:\ndefault integer output decimal-separated output accounting-style output base conversion output The Product Viewer application used a product reader interface to retrieve product information through an implementation class.\nThis matters because interfaces support cleaner design, easier replacement of components, and more flexible code. In cybersecurity and ServiceNow work, this kind of thinking helps with understanding APIs, connectors, integrations, workflow contracts, and data abstraction.\nCapability-to-Evidence Map # Capability Evidence from IST 242 Status Intermediate Java Programming Built multiple Java applications using classes, constructors, methods, control flow, arrays, formatting, console interaction, packages, and application entry points. Completed Object-Oriented Application Design Modeled domain entities such as customers, products, people, employees, managers, executives, and financial calculations using object-oriented structure. Completed Inheritance and Abstraction Used inheritance, abstract classes, method overriding, and specialized subclasses in Person/Employee/Student and HR Management examples. Completed Interface-Driven Design Used NumberFormatter and ProductReader interfaces to define behavior contracts and support interchangeable implementations. Completed GUI Development Built a Swing Future Value Calculator with text fields, buttons, labels, layout handling, event listeners, and formatted output. Completed Input Validation Separated validation logic from GUI behavior to support cleaner input handling and more reliable user-facing application behavior. Completed Difference from IST 240 and IST 311 # IST 242 fits between introductory programming and more advanced software engineering/data structure work.\nCourse Main Portfolio Angle Best Evidence Type IST 240 Introductory Java programming, basic classes, object creation, constructors, methods, inheritance introduction, arrays, and ArrayLists. Programming Foundations IST 242 Intermediate Java application development, interfaces, polymorphism, abstract classes, GUI development, validation, and cleaner application structure. Intermediate OOP IST 311 More advanced data structures, object-oriented design, Big-O analysis, UML/CRC modeling, testing, debugging, Git workflow, and software engineering foundations. Software Engineering Together, these pages show progression from introductory programming to intermediate application development and then to stronger software engineering foundations.\nCybersecurity Relevance # This project supports cybersecurity work indirectly by strengthening application development fluency.\nThe cybersecurity value is that it supports the ability to:\nunderstand application behavior reason about object-oriented code read Java classes and interfaces understand user input handling recognize validation logic understand GUI-driven workflows communicate with developers build small internal tools reason about APIs and implementation contracts understand platform scripting and object models transition into security automation and secure software review This is especially relevant to ServiceNow work because the platform involves tables, fields, records, scripts, integrations, workflow logic, user-facing forms, validation behavior, and role-based application design.\nWhat I Learned # This course reinforced several practical development lessons:\nobject-oriented code is easier to manage when classes have clear responsibilities inheritance should be used carefully to represent real shared behavior abstract classes can enforce common structure while allowing specialized subclasses interfaces make applications more flexible by separating contracts from implementations GUI applications require attention to user input, layout, events, and output formatting validation should be handled deliberately instead of trusting user input model classes and data-access classes should be separated from user interaction where possible formatting and output logic should be reusable small applications still benefit from cleaner structure programming skills support later cybersecurity, automation, and platform work Professional Relevance # This project supports roles and tasks involving:\ncybersecurity analysis ServiceNow SecOps consulting scripting and automation foundations application troubleshooting secure software awareness user input validation awareness interface/API understanding workflow and form logic vulnerability management support communicating with developers understanding application behavior It also supports my ServiceNow SecOps direction because ServiceNow work often benefits from understanding object models, data access, scripts, UI behavior, validations, workflow logic, and structured troubleshooting.\nPortfolio-Safe Redaction Notes # This case study intentionally excludes:\nraw Java source code complete lab solutions full project ZIP contents private course instructions private academic records complete assignment answers copy-paste-ready implementation details The goal is to show intermediate Java and application-development progression without publishing raw academic work.\nRelated Portfolio Areas # Software Foundations # This work supports Java, OOP, interfaces, polymorphism, GUI development, validation, and application structure.\nSoftware Foundations\nCybersecurity Analysis # Programming fluency supports tool use, automation, debugging, secure software awareness, log parsing, malware analysis foundations, and understanding application behavior.\nCybersecurity-Relevant\nServiceNow SecOps # ServiceNow work benefits from understanding objects, records, fields, scripts, validations, user interfaces, and workflow behavior.\nSecOps-Relevant\nAcademic Progression # IST 242 connects introductory programming from IST 240 to stronger data structures and software engineering work in IST 311.\nProgression\nNext Steps # This project can later be connected to:\nthe software foundations capability section the IST 240 and IST 311 project pages a programming foundations review path a ServiceNow scripting-readiness note a cybersecurity automation foundations section an application validation and secure input concept note For now, this page serves as the main portfolio-safe summary of my IST 242 intermediate Java and object-oriented application development lab progression.\n","date":"5 June 2026","externalUrl":null,"permalink":"/projects/ist-242-intermediate-java-object-oriented-application-development/","section":"Projects","summary":"","title":"IST 242: Intermediate Java \u0026 Object-Oriented Application Development","type":"projects"},{"content":" Application Development Design Studio Case Study\nThis portfolio-safe case study summarizes selected IST 261 Application Development Design Studio I work focused on designing and building a Java-based Productivity Assistant application using object-oriented modeling, noun/verb analysis, MVC architecture, persistent data planning, GUI list/detail workflows, task queues, employee/task management, and testing.\nCourse IST 261 Project Type Application Development Design Studio Primary Project Productivity Assistant Focus Java · OOP · MVC · Persistence · Collections · GUI Concepts Task Queue · Employee Model · Reports · List/Detail Views · Testing Publishing Level Portfolio-Safe / No Raw Source Published Overview # IST 261 was an application development design studio course centered on planning, designing, iterating, and implementing a Java application.\nThe primary project was a Productivity Assistant concept for remote-work task tracking. The application idea focused on helping employers assign and monitor work while allowing employees to track tasks, time, breaks, progress, and reports without invasive remote monitoring.\nThis course is valuable in my portfolio because it connects several important software-development areas:\nproject proposal writing domain analysis noun/verb analysis class identification object-oriented modeling Java application development MVC architecture persistent data strategy task and employee data structures queue-based task assignment GUI list/detail workflows testing privacy-aware product thinking This page is intentionally written as a portfolio-safe summary. It does not publish raw Java source code, full project ZIP contents, private course instructions, complete academic submissions, or copy-paste-ready implementation details.\nWhy This Project Matters # IST 261 is one of the clearest examples of my Application Development focus area because it moved beyond individual programming exercises and into a more complete application design process.\nThe work required thinking through:\nwhat problem the application solves who the users are what data the system needs which classes represent the domain which methods support user actions how data should persist after runtime how GUI views should interact with controller logic how task data should be stored and retrieved how test cases support application reliability how privacy concerns affect product design That makes this page a stronger software-design artifact than a simple programming lab.\nPortfolio-Safe Publishing Approach # Security and academic integrity note: This case study summarizes application design and Java development work without publishing raw source code, full project ZIP contents, complete academic submissions, private course materials, or copy-paste-ready solutions.\nThis page excludes:\nraw Java source code complete project ZIP contents full academic submissions private course instructions complete assignment answers private student identifiers copy-paste-ready implementation details full screenshots or IDE files Instead, it presents:\ndesign process application concept object model architecture themes data strategy testing approach software engineering lessons cybersecurity and ServiceNow relevance Project Concept: Productivity Assistant # The Productivity Assistant was designed as a remote-work productivity application.\nThe core idea was to support two major user groups:\nemployers, who need task visibility, project progress, assignment tracking, and reporting employees, who need a way to manage tasks, track work time, track breaks, and generate reports without intrusive monitoring The application concept was privacy-aware. Rather than building remote surveillance software, the idea focused on user-directed productivity tracking and report generation.\nThis distinction matters because application design is not only technical. Product decisions affect privacy, trust, user adoption, workflow clarity, and organizational risk.\nMajor Workstreams # Project Proposal # Defined the application domain, problem opportunity, proposed solution, user needs, privacy concerns, productivity goals, technical risks, and design challenges.\nProposal\nNoun/Verb Analysis # Identified core domain objects and behaviors such as Employer, Employee, Task, Report, task assignment, task selection, time tracking, break tracking, and report generation.\nDomain Analysis\nObject-Oriented Modeling # Built Java classes representing people, employees, managers, workgroups, tasks, reports, employee lists, task lists, and related application behavior.\nOOP\nMVC Architecture # Worked with model-view-controller structure, including controller actions, views, list/detail screens, table models, and employee data management.\nMVC\nPersistent Data Strategy # Planned how employee and task data should be stored, loaded, updated, and handled across runtime sessions.\nPersistence\nCollections and Task Queue # Identified where collections were needed, including task queue behavior for first-in-first-out task assignment and employee data structures for availability tracking.\nCollections\nGUI List/Detail Workflow # Developed list and detail views for employee-style records, including create, show details, update, delete, save, and quit-style actions.\nGUI Workflow\nTesting # Created manual test and JUnit-style test artifacts for selected application components, including task queue and workgroup-related behavior.\nTesting\nApplication Development Evidence # Artifact / Area Portfolio-Safe Summary Concept Project Proposal Defined the Productivity Assistant concept, remote-work problem space, employer/employee user needs, privacy considerations, productivity reporting goals, risks, and design constraints. Requirements Noun/Verb Analysis Identified likely classes and behaviors, including Employer, Employee, Task, Report, assignment, selection, work tracking, break tracking, and report generation. Analysis Productivity Assistant Classes Developed Java classes such as Employee, Manager, Person, Task, Report, WorkGroup, and related test harnesses to model the application domain. Java / OOP MVC Implementation Worked with controller logic, view components, employee model objects, list/detail views, and GUI-driven application behavior. MVC Persistent Data Strategy Planned persistence for employee and task data, including data fields, update frequency, runtime loading, error handling, and long-term maintainability concerns. Persistence Task Queue Design Used queue-style thinking for task handling where tasks should be processed in first-in-first-out order based on when work arrives. Queue Employee and Task Lists Worked with employee and task list structures, including add, get, set, remove, read, write, print, and list retrieval style operations. Data Structures Manual and Automated Testing Created test artifacts for selected components, including workgroup behavior and task queue behavior. Testing Technical Workflow # 1 Define the Problem and Users # Started with a project proposal focused on remote-work productivity, employer reporting, employee self-tracking, privacy concerns, and productivity improvement.\nProposal\n2 Identify Nouns, Verbs, and Classes # Used noun/verb analysis to identify core classes, data fields, user actions, and candidate methods.\nDomain Analysis\n3 Build the Object Model # Developed Java classes for people, employees, managers, workgroups, tasks, and reports to represent the application domain.\nOOP Model\n4 Add MVC Structure # Moved toward model-view-controller structure using controller actions, employee model objects, table models, and list/detail views.\nMVC\n5 Plan and Implement Persistence # Planned how employee and task data should be stored, loaded, updated, and recovered across sessions.\nPersistence\n6 Add Collections and Task Queue Logic # Identified queues and other data structures for task handling, employee availability, and evolving task/employee datasets.\nCollections\n7 Test and Refine # Created manual and automated test artifacts to validate selected application behavior and support better reliability.\nTesting\nDomain Model Summary # The Productivity Assistant project centered around a small but meaningful application domain.\nClass / Component Purpose Design Role Person Represented shared identity fields such as name, ID, phone number, address, and date-of-birth style details. Base Class Employee Represented an employee user who can receive tasks, track work, generate reports, and participate in workgroup behavior. User Model Manager Represented employer/manager behavior such as adding employees, assigning tasks, and reviewing employee count or related activity. Manager Model Task Represented work items with name, type, description, due date, priority level, and completion status. Work Item Report Represented productivity and work-summary reporting concepts for employee and employer use cases. Reporting WorkGroup Represented a group of employees and related workgroup metadata such as name, description, and start date. Grouping EmployeeList / TaskList Represented collections of employees and tasks with add, get, set, remove, read, write, print, and retrieval-style behavior. Collections TaskQueue Represented task queue behavior where tasks can be added, examined, searched, retrieved, and persisted. Queue MVC and GUI Evidence # The later implementation work included MVC-style structure and GUI list/detail behavior.\nKey elements included:\ncontroller actions list view behavior detail view behavior table model use employee row display create action show details action update action delete action save action quit action next task display separation between model data and view behavior This is important because MVC-style thinking maps closely to professional application design. It encourages separation between data, interface, and control logic instead of placing all behavior in one file.\nPersistent Data Strategy # The persistent data strategy focused on two major data areas:\nemployee data task data Employee data included fields such as name, ID, address, phone number, email address, and hourly rate. This data needs persistence because employees may be added, removed, or updated over time.\nTask data included task description, due date, priority level, completion status, and history. This data needs persistence because task records change frequently and may be updated many times during the workday.\nThe design also considered:\nloading data at application startup saving data after changes file-not-found and error handling human-readable storage tradeoffs security concerns for sensitive HR-style data the difference between frequently changing task data and less frequently changing employee data This was a strong design exercise because persistence decisions affect security, privacy, reliability, maintainability, and user trust.\nCollections and Data Structure Decisions # The project included a specific analysis of where collections should be used.\nThe task workflow was a good fit for a queue because tasks should be assigned or processed in the order they arrive. That maps to first-in-first-out behavior.\nEmployee availability was treated differently. Employees may become available in non-sequential order, and the application needs to identify an available employee rather than only process one fixed sequence. This encouraged thinking about different collection types and why one data structure is not always appropriate for every problem.\nConcepts covered included:\nqueue behavior first-in-first-out task handling employee availability tracking vector/list-style access linked list wrapper concepts add/get/set/remove operations searching tasks examining queue contents reading and writing list data serialized persistence artifacts Testing Evidence # Testing artifacts supported selected project components.\nThe project included:\nmanual testing artifacts JUnit-style test artifacts Employee-related tests WorkGroup-related tests TaskQueue tests test harness behavior component-level validation thinking The most important portfolio value is not the exact test code. The value is that the application was treated as something that should be validated, not just written once and assumed to work.\nSoftware Design Skills Demonstrated # Skill Evidence from IST 261 Status Requirements Thinking Defined employer and employee needs, remote-work productivity goals, privacy concerns, reporting needs, task priority, reminders, and adoption constraints. Completed Domain Analysis Used noun/verb analysis to identify candidate classes, fields, methods, user actions, and system responsibilities. Completed Object-Oriented Modeling Modeled Person, Employee, Manager, Task, Report, WorkGroup, EmployeeList, TaskList, and TaskQueue concepts. Completed MVC Architecture Worked with controller logic, views, model objects, table models, list/detail screens, and GUI event behavior. Completed Persistent Data Planning Planned storage and retrieval for employee and task data, including startup loading, data changes, error handling, and security considerations. Completed Collection Selection Analyzed when to use queues, lists, and other data structures for task processing and employee availability tracking. Completed Testing Created manual and automated test artifacts for selected classes and data structure behavior. Completed Privacy and Security Considerations # The Productivity Assistant concept included privacy and security concerns from the beginning.\nThe proposal distinguished between productivity tracking and invasive remote monitoring. The application concept focused on user-directed work tracking and report generation instead of constant surveillance.\nThe design also recognized that employee and task data may contain sensitive business and HR-related information.\nSecurity and privacy considerations included:\navoiding invasive remote monitoring considering what data should and should not be accessible recognizing HR-style data sensitivity understanding that data storage choices affect privacy considering unauthorized access risks recognizing the need for encryption in a real-world system understanding that application design decisions affect downstream security designing for user trust and adoption This makes IST 261 useful not only as a software project, but also as evidence of security-aware product thinking.\nDifference from IST 240, IST 242, and IST 311 # IST 261 fits into the software-development progression differently from the other programming courses.\nCourse Main Portfolio Angle Best Evidence Type IST 240 Introductory Java programming, basic OOP, class design, inheritance introduction, arrays, and ArrayLists. Programming Foundations IST 242 Intermediate Java application development, interfaces, polymorphism, GUI development, validation, and cleaner application structure. Intermediate OOP IST 261 Application design studio work involving proposal writing, domain analysis, MVC, persistence strategy, GUI list/detail workflow, collections, task queues, and testing. Design Studio IST 311 More advanced data structures, software engineering foundations, Big-O, testing, debugging, UML/CRC, and Git workflow. Software Engineering Together, these courses show a progression from basic Java programming to intermediate OOP, application design, and stronger software engineering foundations.\nCybersecurity and ServiceNow Relevance # This project supports cybersecurity and ServiceNow work indirectly but meaningfully.\nThe cybersecurity value comes from understanding:\nhow applications are designed how domain objects become classes how data is stored and persisted how task workflows are modeled how GUI workflows affect users how data structure choices affect behavior how privacy concerns should influence application design how testing supports reliability how business requirements become technical behavior The ServiceNow relevance is also clear. ServiceNow work often involves:\nrecords tables fields task assignment work queues ownership reporting workflows forms UI actions data persistence role-based access process design requirements gathering stakeholder communication IST 261 supports that foundation by showing application design and workflow thinking before implementation.\nWhat I Learned # This course reinforced several lessons:\ngood applications start with a clear problem and user need noun/verb analysis helps turn requirements into classes and methods object models should reflect the real domain privacy and user trust should be considered early in the design process MVC helps separate data, user interface, and control logic persistence must be planned before data becomes important employee data and task data have different access and update patterns queues are useful when order of arrival matters testing should validate components rather than relying only on manual use GUI workflow should be understandable to users application design choices affect security, maintainability, and adoption Professional Relevance # This project supports roles and tasks involving:\nServiceNow SecOps consulting cybersecurity analysis application design requirements gathering workflow modeling task management systems vulnerability management support technical documentation data modeling software troubleshooting privacy-aware product thinking stakeholder communication testing and validation It is especially relevant to ServiceNow because ServiceNow implementations are built around process design, data models, task records, assignment logic, workflows, reporting, and user-facing forms.\nPortfolio-Safe Redaction Notes # This case study intentionally excludes:\nraw Java source code complete project ZIP contents full academic submissions complete assignment answers private course instructions private student identifiers copy-paste-ready implementation details full screenshots or IDE files The goal is to show application design, modeling, architecture, and software-development progression without publishing raw academic work.\nRelated Portfolio Areas # Application Development # This work supports Java application design, domain analysis, OOP modeling, MVC, persistence, collections, GUI workflows, and testing.\nApplication Development\nServiceNow SecOps # Task assignment, reporting, work queues, ownership, persistence, and workflow modeling map naturally to ServiceNow implementation thinking.\nSecOps-Relevant\nCybersecurity Analysis # Application design knowledge supports understanding data flow, user behavior, persistence, privacy risks, and how software decisions affect security.\nCybersecurity-Relevant\nHCI and Workflow Design # The project considered user experience, usability, employer/employee workflows, privacy concerns, and adoption barriers.\nHCI-Relevant\nNext Steps # This project can later be connected to:\nthe software foundations capability section the Application Development focus area in education the ServiceNow workflow design narrative a task assignment workflow concept a persistence and data governance note a workflow modeling / HCI evidence section the IST 240, IST 242, and IST 311 progression path For now, this page serves as the main portfolio-safe summary of my IST 261 Application Development Design Studio I work.\n","date":"5 June 2026","externalUrl":null,"permalink":"/projects/ist-261-productivity-assistant-application-design-studio/","section":"Projects","summary":"","title":"IST 261: Productivity Assistant Application Design Studio","type":"projects"},{"content":" HCI / User-Centered Design Case Study\nThis portfolio-safe case study summarizes selected IST 331 Foundations of User-Centered Design work focused on interface evaluation, user profiles, user research, workflow analysis, low-fidelity prototyping, high-fidelity prototyping, usability testing, Figma collaboration, and iterative redesign of a travel-booking interface.\nCourse IST 331 Project Type User-Centered Design / HCI Case Study Primary Project Booking.com Interface Redesign Focus User Research · Prototyping · Usability Testing · Iterative Redesign Tools / Methods Figma · Interviews · User Profiles · Low-Fi Prototype · High-Fi Prototype Publishing Level Portfolio-Safe / No Raw Participant Data Published Overview # IST 331 focused on foundations of user-centered design. The course emphasized how interfaces should be evaluated, researched, prototyped, tested, and improved based on user needs rather than designer assumptions.\nThe primary group project was a redesign of Booking.com. The project focused on reducing clutter, improving navigation, making travel-planning paths easier to understand, improving filtering, making important actions easier to find, adding feedback for completed actions, and improving user confidence during booking-related tasks.\nThe course also included individual work on user-friendly interfaces, user profiles, digital native versus digital immigrant differences, collaboration tools, and a usability testing lab.\nThis page is intentionally written as a portfolio-safe summary. It does not publish raw participant names, private interview responses, complete academic submissions, full Figma files, or complete group project artifacts.\nWhy This Project Matters # This project matters because my portfolio itself is built around HCI and security-first thinking.\nGood security workflows are not only technically correct. They must also be usable.\nPoor usability can lead to:\nusers clicking the wrong control users missing important warnings users abandoning workflows users making security mistakes reviewers failing to find important evidence analysts missing next steps teams building processes that are hard to follow IST 331 helped strengthen my understanding of how user needs, interface structure, workflow clarity, feedback, error prevention, and iterative testing affect whether a system actually works for people.\nThat is directly relevant to cybersecurity, ServiceNow SecOps, vulnerability response, GRC workflows, incident response workflows, and this portfolio website.\nPortfolio-Safe Publishing Approach # Privacy note: This page summarizes user research and usability testing work without publishing raw participant names, private responses, complete interview notes, full academic submissions, or private prototype links.\nThis page excludes:\nraw participant names private interview responses full survey/interview data private Figma project links complete group submissions private student identifiers complete academic answers raw usability test notes full presentation files Instead, it presents:\ndesign goals research approach usability themes testing summary design changes HCI lessons learned portfolio-safe outcomes Major Workstreams # Interface Evaluation # Evaluated user-friendly and difficult interfaces, including how clutter, unclear navigation, hidden features, and lack of feedback affect usability.\nInterface Review\nUser Profiles # Compared different user backgrounds and technology experience levels to understand how prior experience affects expectations, comfort, and risk awareness.\nUser Profiles\nProject Proposal # Defined the Booking.com redesign problem, expected users, interface issues, business impact, and improvement goals.\nProposal\nUser Research # Focused on business professionals and college students as target user groups, then collected feedback about travel-booking expectations and interface pain points.\nUX Research\nLow-Fidelity Prototype # Created early prototype concepts to explore layout, navigation, booking flow, information organization, and screen structure before final visual polish.\nLow-Fi Prototype\nHigh-Fidelity Prototype # Developed a higher-fidelity Figma prototype for the redesigned booking experience, including improved navigation and more complete user flows.\nHigh-Fi Prototype\nUsability Testing # Tested prototype tasks with users, collected timing/click data, captured success outcomes, and used the results to guide revisions.\nUsability Testing\nIterative Redesign # Modified the high-fidelity prototype based on design principles, usability findings, and feedback.\nIteration\nBooking.com Redesign Problem # The group selected Booking.com because the interface presented several usability concerns.\nIdentified issues included:\ntoo much visual clutter overloaded information on the homepage weak focus around destination selection recommended destinations that did not feel clearly ordered filter controls that needed redesign hidden or difficult-to-find features profile-menu ambiguity unclear path back from sign-in/sign-up flows uncertainty after completing certain account actions flight search information overload travel-planning flows that could feel less streamlined than expected The main design goal was to help users find relevant travel options more easily while reducing unnecessary clutter and improving clarity.\nUser Research # The group focused on two user groups:\nbusiness professionals college students These groups were selected because they were accessible to the team and represented users who might use travel-booking websites for different reasons.\nThe user research considered:\ncomfort with laptops, desktops, and mobile devices travel-booking expectations business versus personal travel needs information overload filtering needs ease of navigation booking confidence interface clarity user frustration points The goal was to understand what users needed before deciding what to redesign.\nDesign and Testing Workflow # 1 Identify Interface Issues # Reviewed Booking.com and identified clutter, hidden features, confusing navigation, weak feedback, and filter/search issues.\nInterface Review\n2 Define Users and Goals # Defined target user groups, expected user needs, and redesign goals around clarity, navigation, filtering, and reduced cognitive load.\nUser Research\n3 Create Low-Fidelity Prototype # Produced early design concepts to test structure, layout, and flow before focusing on polished visuals.\nLow-Fi Prototype\n4 Build High-Fidelity Prototype # Created a more complete Figma prototype with redesigned screens and improved user flows.\nHigh-Fi Prototype\n5 Run Usability Testing # Asked users to complete tasks, collected task success, elapsed time, click counts, and subjective design ratings.\nUsability Testing\n6 Apply Design Revisions # Modified the prototype using usability results and design principles such as feedback, consistency, error prevention, help, and universal usability.\nIteration\nUsability Testing Evidence # The individual usability testing lab collected task data from five participants using different devices.\nPortfolio-safe summary of the test data:\nMetric Result Interpretation Participants Five participants completed the task scenario. Sample Successful Outcome All participants completed the task successfully. 100% Success Average Elapsed Time Average task completion time was approximately 53.3 seconds. Time-on-Task Average Clicks Average click count was approximately 8.6 clicks. Efficiency Design Rating Average perceived design rating was approximately 4.2 out of 5. Satisfaction This test helped connect usability to measurable outcomes rather than relying only on opinion.\nPrototype Modification Evidence # The high-fidelity prototype modifications were tied to established usability principles.\nDesign Principle Modification Usability Goal Dialogs Yield Closure Added confirmation behavior for successful login and account creation so users receive clear feedback that an action was completed. Feedback Universal Usability Created a bookings page where users can view reservations in one centralized location. Accessibility Efficiency of Use Added easier access to reservations so users do not need to search through emails or hidden menus to track bookings. Efficiency Error Prevention Added calendar overlay behavior for flight and stay date selection to reduce invalid input and prevent format errors. Error Prevention Help and Documentation Adjusted the help link so users could reach relevant help resources more directly. Help Consistency Improved navigation and interface behavior so actions and pages felt more predictable across the prototype. Consistency Collaboration and Tooling # The group used multiple collaboration tools during the course.\nThe available evidence supports:\nCanvas messaging for initial communication Microsoft Teams for group communication and coordination document sharing and meeting planning Figma for prototype collaboration shared deliverables across proposal, research, prototype, usability testing, and final presentation This matters professionally because user-centered design is collaborative. The quality of a design project depends not only on individual ideas, but also on coordination, communication, versioning, and shared understanding.\nHCI Concepts Demonstrated # Cognitive Load Reduction # The redesign focused on reducing clutter, simplifying decision paths, and making travel-planning actions easier to identify.\nCognitive Load\nFeedback and Closure # Confirmation behavior helped users understand when login or account creation actions were completed.\nFeedback\nError Prevention # Calendar overlays reduced the chance of invalid date input and made date selection more familiar to users.\nError Prevention\nWorkflow Clarity # The redesign attempted to make reservations, bookings, search, filters, and navigation easier to find and follow.\nWorkflow\nUser Research # The project used target user groups and interviews to support design decisions rather than relying only on assumptions.\nResearch\nUsability Testing # The work included task testing, time-on-task, click counts, success outcomes, and design rating analysis.\nTesting\nCapability-to-Evidence Map # Capability Evidence from IST 331 Status User-Centered Design Developed a redesign based on user groups, interface issues, user expectations, and iterative feedback. Completed Interface Evaluation Evaluated interfaces for clutter, hidden features, weak feedback, navigation issues, and information overload. Completed User Research Focused on business professionals and college students to understand different travel-booking needs, expectations, and pain points. Completed Prototyping Produced low-fidelity and high-fidelity prototype artifacts for a redesigned travel-booking interface. Completed Usability Testing Collected task success, elapsed time, click count, and subjective design rating data from usability testing. Completed Iterative Redesign Modified the prototype using principles such as feedback, universal usability, error prevention, help, and consistency. Completed Cybersecurity and ServiceNow Relevance # This course supports cybersecurity and ServiceNow work because security tools and workflows need to be usable.\nIn cybersecurity environments, usability affects:\nwhether analysts notice the right evidence whether users follow security procedures whether workflows are adopted consistently whether alerts, dashboards, and forms guide people correctly whether risky actions are prevented before they occur whether users understand confirmation, errors, and next steps whether a system supports both novice and experienced users For ServiceNow SecOps specifically, HCI concepts matter because Vulnerability Response and Security Incident Response workflows depend on forms, records, queues, assignments, dashboards, status transitions, and user actions.\nA technically correct workflow can still fail if users do not understand what to do next.\nConnection to This Portfolio Website # IST 331 directly supports the design philosophy behind this portfolio.\nMany improvements to this site are based on HCI principles:\nclearer Start Here path role-based review paths stronger distinction between clickable buttons and static labels mobile usability improvements card-based navigation guided review workflow consistent course-coded project naming privacy-aware publishing approach reduced ambiguity around next steps This course gives academic support to the same usability thinking applied throughout sudoRunner.\nWhat I Learned # This course reinforced several lessons:\nusers should not have to guess where to go next clutter increases cognitive load hidden features reduce efficiency confirmation messages help users feel confident error prevention is better than error correction usability testing should measure behavior, not just opinions low-fidelity prototypes are useful before investing in visual polish high-fidelity prototypes should still be tested and revised different user groups may have different expectations collaboration tools matter in design projects HCI principles apply to cybersecurity workflows, not only consumer apps Professional Relevance # This project supports roles and tasks involving:\nServiceNow SecOps consulting cybersecurity workflow design user-centered security process design analyst dashboard usability vulnerability management workflow design security operations process improvement requirements gathering stakeholder communication prototyping usability testing HCI-aware portfolio design It is especially relevant to ServiceNow work because ServiceNow implementations must be usable by analysts, managers, assignment groups, and business stakeholders.\nDifference from IST 402 Workflow Modeling # IST 331 and IST 402 both relate to workflow design, but they show different strengths.\nCourse Main Portfolio Angle Best Evidence Type IST 331 User-centered design, user research, interface evaluation, prototyping, usability testing, and iterative redesign. HCI / UX IST 402 Cloud, emerging technology, workflow modeling, infrastructure, containers, zero trust, and cloud security strategy. Cloud / Workflow Together, they support both user-centered design and technical workflow modeling.\nPortfolio-Safe Redaction Notes # This case study intentionally excludes:\nraw participant names private interview responses complete test notes complete survey data full group submissions private Figma links complete prototype files private academic records complete presentation files The goal is to show HCI process, usability evidence, and design reasoning without exposing raw academic or participant data.\nRelated Portfolio Areas # HCI and Usability # This work supports user-centered design, usability testing, workflow clarity, user feedback, error prevention, and iterative redesign.\nHCI\nServiceNow SecOps # SecOps workflows need clear forms, queues, dashboards, status transitions, assignment paths, validation steps, and next-action guidance.\nSecOps-Relevant\nPortfolio Design # The course supports the design decisions used throughout sudoRunner, including guided review paths, mobile polish, and clearer clickable versus static elements.\nPortfolio-Relevant\nSecurity Process Design # Security programs fail when workflows are confusing. HCI helps make security processes more usable, repeatable, and adoption-friendly.\nSecurity Workflow\nNext Steps # This project can later be connected to:\nthe HCI capability section the sudoRunner Portfolio Website project ServiceNow workflow usability notes a security dashboard usability concept a vulnerability response workflow HCI checklist a role-based reviewer journey note a mobile usability audit section For now, this page serves as the main portfolio-safe summary of my IST 331 Foundations of User-Centered Design work.\n","date":"5 June 2026","externalUrl":null,"permalink":"/projects/ist-331-user-centered-design-booking-redesign/","section":"Projects","summary":"","title":"IST 331: User-Centered Design \u0026 Booking.com Redesign Case Study","type":"projects"},{"content":" Cloud / Emerging Technologies Case Study\nThis portfolio-safe case study summarizes selected IST 402 Emerging Issues and Technologies work focused on cloud computing, virtualization, Microsoft Hyper-V, OpenStack private cloud, Docker containers, cloud network security, zero trust, mutual TLS, secure cloud architecture, workflow modeling, shared responsibility, cloud migration planning, and Security-as-a-Service strategy.\nCourse IST 402 Project Type Cloud / Emerging Technologies Lab Collection Focus Virtualization · Containers · Zero Trust · Cloud Security · SECaaS Tools / Platforms Hyper-V · OpenStack · Docker · Docker Compose · Wazuh · OpenSCAP Security Concepts mTLS · Certificates · Docker Registry Security · Shared Responsibility Professional Angle Cloud Infrastructure, Cloud Security, Workflow Modeling, and Security Strategy Overview # IST 402 covered emerging issues and technologies with a strong emphasis on cloud computing, virtualization, infrastructure abstraction, containers, cloud migration, security operations, workflow modeling, and technology strategy.\nThis course is valuable in my portfolio because it connects practical infrastructure work with cybersecurity decision-making. The lab work involved building and configuring virtualized and cloud-based environments, working with containers, evaluating secure cloud architecture, exploring cloud network security controls, and presenting a Security-as-a-Service strategy.\nThe strongest portfolio angle is cloud security and emerging technology readiness: understanding how infrastructure, identity, certificates, containers, monitoring, architecture, workflow, and executive security strategy fit together.\nThis page is intentionally written as a portfolio-safe summary. It does not publish raw screenshots, complete lab submissions, private student details, full academic materials, credentials, internal diagrams, or step-by-step lab procedures.\nWhy This Project Matters # Cybersecurity work increasingly depends on understanding the infrastructure underneath the alerts.\nCloud security, ServiceNow SecOps, vulnerability response, and security operations all benefit from understanding:\nhow virtual machines are provisioned and networked how cloud services abstract infrastructure ownership how containers are built, connected, secured, and deployed how certificate-based trust affects cloud network access how mutual TLS can enforce stronger service-to-service authentication how private cloud platforms expose compute, identity, networking, and dashboard services how shared responsibility changes risk ownership how continuous monitoring supports cloud security how cloud-native security products are evaluated and justified how user workflows can be mapped into systems and security requirements how technical findings are translated into business-facing recommendations IST 402 helped connect these areas into a broader technical and strategic picture.\nPortfolio-Safe Publishing Approach # Security note: This case study summarizes lab, workflow, and presentation work without publishing raw lab screenshots, credentials, IP details, complete command history, private student identifiers, full submissions, complete internal diagrams, certificate artifacts, or full vendor materials.\nThis page excludes:\nraw screenshots full lab reports exact credentials private academic records private student identifiers full command output certificate material complete step-by-step lab procedures raw presentation files full vendor comparison details complete workflow source diagrams Instead, it presents:\nhigh-level technical themes tools and platforms used infrastructure concepts cloud security lessons zero trust and mTLS concepts workflow modeling evidence portfolio-safe summaries professional lessons learned Major Workstreams # Microsoft Hyper-V Virtualization # Configured virtual machines, networking, resource allocation, PowerShell-based VM management, private network connectivity, integration services, and checkpoints.\nVirtualization\nOpenStack Private Cloud # Built private cloud components involving controller services, identity/token behavior, compute services, networking, Horizon dashboard access, flavors, and additional compute resources.\nPrivate Cloud\nDocker Containers # Worked with container image builds, Docker run behavior, environment variables, file mounting, multi-container applications, container networking, and Docker Compose.\nContainers\nCloud Network Security # Worked through cloud network security concepts involving certificate trust, root certificates, registry certificates, certificate authority errors, bad certificate validation, Docker registry access, and mutual TLS.\nZero Trust\nSecure Cloud Architecture # Designed and evaluated secure cloud architecture concepts involving network diagrams, OpenSCAP testing, SSH hardening, Wazuh monitoring, container events, and security profile management.\nCloud Security\nWorkflow Modeling # Created a user-access workflow diagram modeling application access, QR-code login, server/channel interaction, file sharing, voice call behavior, settings, and logout flow.\nProcess Modeling\nShared Responsibility # Course reflections covered shared responsibility, ownership tradeoffs, infrastructure cost, provider-managed controls, automation, Kubernetes, metrics, and hyperconverged infrastructure.\nCloud Governance\nSecurity-as-a-Service Strategy # The final presentation evaluated SECaaS, CrowdStrike Falcon, cloud-native security, continuous monitoring, threat intelligence, automated response, compliance, cost reduction, and executive approval.\nSECaaS\nCloud Infrastructure Lab Evidence # Lab / Topic Portfolio-Safe Summary Focus Hyper-V Virtualization Configured virtual machines, adjusted memory and CPU resources, validated network connectivity between Windows and Linux VMs, reviewed integration services, and created VM checkpoints. Virtualization OpenStack Private Cloud Set up private cloud services, reviewed project/user/role relationships, generated token information, configured compute services, validated active compute nodes, accessed Horizon, created flavors, and added compute resources. OpenStack Docker Containers Built and ran containers, reviewed working directories and environment variables, configured multi-container applications, created Docker networks, tested application behavior, and worked with Docker Compose. Docker Cloud Network Security Created certificate material for mutual TLS, reviewed root and registry certificates, observed certificate authority and bad certificate errors, validated Docker registry pull behavior, and tested web service access with mutual TLS enabled. mTLS Secure Cloud Architecture Designed cloud architecture diagrams, reviewed OpenSCAP findings, remediated SSH empty-password control issues, validated passing tests, reviewed Wazuh events, and monitored image/container activity. Cloud Security Workflow Modeling Created a user access workflow diagram for Discord covering login flow, QR-code access, server/channel selection, file sharing, voice call behavior, settings navigation, and logout confirmation. HCI / Workflow Cloud Strategy Reflections Course reflection work covered SaaS, private/public cloud migration planning, RFI considerations, shared responsibility, infrastructure automation, Kubernetes, storage, APIs, VDI, NSX, and cloud/mobile usability. Emerging Tech SECaaS Executive Presentation Group presentation proposed Security-as-a-Service adoption for a fictional enterprise, evaluated CrowdStrike Falcon capabilities, and explained security, cost, compliance, operational, and implementation considerations. Security Strategy Technical Workflow # 1 Build the Virtual Infrastructure Foundation # Started with virtualization concepts: VM resource allocation, virtual networking, PowerShell-based management, guest/host integration, and checkpoints.\nHyper-V\n2 Deploy Private Cloud Services # Moved into private cloud concepts by configuring OpenStack services, identity, compute, networking, Horizon dashboard access, and additional compute capacity.\nOpenStack\n3 Containerize Application Components # Worked with Docker images, containers, file access, environment variables, networking, multi-container application patterns, and Docker Compose.\nDocker\n4 Apply Cloud Network Security Controls # Tested certificate-based trust, mutual TLS, Docker registry access behavior, certificate validation failure modes, and service access when stronger authentication was enabled.\nmTLS / Zero Trust\n5 Validate Secure Configuration and Monitoring # Reviewed cloud hardening concepts through OpenSCAP, SSH control validation, Wazuh monitoring, container event visibility, and secure configuration testing.\nCloud Security\n6 Model User and System Workflows # Mapped a user-access flow to understand application steps, authentication points, user decisions, interaction paths, and logout behavior.\nWorkflow Modeling\n7 Translate Technology into Strategy # Connected cloud operations to business decisions through shared responsibility, vendor evaluation, SECaaS, CrowdStrike Falcon, compliance, monitoring, incident response, and executive communication.\nSecurity Strategy\nVirtualization Concepts Covered # The Hyper-V lab work helped reinforce foundational virtualization concepts:\nvirtual machine creation and configuration VM memory and processor allocation PowerShell-based VM management virtual network configuration Windows-to-Linux VM connectivity private network validation guest-to-host integration services checkpoint and snapshot concepts resource abstraction high availability and recovery thinking These concepts are useful for security work because endpoint, server, and cloud security often depend on knowing where compute, networking, storage, and management boundaries exist.\nPrivate Cloud Concepts Covered # The OpenStack lab work introduced private cloud architecture concepts:\ncontroller node services identity and project/user/role relationships token generation compute service setup network service configuration Horizon dashboard access Nova compute resources flavors for compute instances adding additional compute capacity validating active compute nodes This experience is relevant because cloud security depends heavily on identity, roles, compute, networking, and management-plane visibility.\nContainer Concepts Covered # The Docker labs reinforced container fundamentals:\nimage build process container execution file access inside containers environment variables container networking database container behavior multi-container application patterns Docker Compose orchestration application service validation troubleshooting build/runtime issues This is useful for cybersecurity because containerized workloads require different thinking from traditional hosts. Security teams must understand images, runtime behavior, exposed services, container networks, dependency issues, and orchestration risk.\nCloud Network Security Concepts Covered # The cloud network security lab added a stronger security architecture layer to the course.\nThe work included:\ncreating certificate material for mutual TLS reviewing root certificate output reviewing registry certificate extensions observing certificate authority trust failures observing bad certificate behavior validating Docker registry pull behavior testing Docker registry access from different systems running frontend and backend containers validating HTTP and HTTPS behavior testing web service access with mutual TLS enabled confirming when direct origin access failed after stronger controls were applied manually checking certificate verification output This is a strong portfolio signal because it shows that cloud security is not only about deploying workloads. It also involves identity, trust, certificate validation, network access control, service-to-service authentication, and failure-mode testing.\nWorkflow Modeling and HCI Concepts Covered # One IST 402 artifact modeled user access to Discord as a workflow diagram.\nThe diagram represented a user moving through:\ncomputer access application launch login UI QR-code login home screen server list joining a server selecting a channel sharing cloud-stored files sending a message answering and ending a voice call settings navigation logout selection logout confirmation This supports my broader portfolio theme around HCI-friendly design and workflow clarity. For cybersecurity and ServiceNow work, workflow modeling matters because analysts and users need clear paths through systems. Confusing workflows can create security mistakes, missed steps, poor adoption, and inconsistent process execution.\nSecure Cloud Architecture Concepts Covered # The secure cloud architecture lab connected infrastructure to security controls.\nKey areas included:\nsecurity-focused architecture planning network diagramming OpenSCAP scanning SSH hardening empty-password control validation Wazuh event monitoring container image pull visibility container start event monitoring security profile management continuous monitoring concepts configuration drift awareness This portion of the course is especially relevant to security operations because it connects infrastructure configuration to measurable security posture.\nSecurity-as-a-Service Strategy # The final presentation focused on a fictional company, Acme Corp, facing major cybersecurity problems and evaluating Security-as-a-Service adoption.\nThe presentation covered:\ncurrent security challenges impact of security failures SECaaS definition and benefits scalability and cost-efficiency access to cybersecurity expertise continuous monitoring incident response threat intelligence preventive security measures advanced detection and automated response behavioral analytics integrated defense CrowdStrike Falcon platform evaluation endpoint security cloud workload protection identity protection compliance considerations implementation concerns and mitigation The most useful portfolio angle is not vendor promotion. The useful angle is that the presentation required translating security technology into executive-facing business value, risk reduction, implementation planning, and governance concerns.\nCloud Security and Governance Lessons # Lesson Why It Matters Professional Relevance Trust Must Be Explicitly Designed Certificate-based authentication and mutual TLS demonstrate that secure communication depends on identity, trust chains, validation behavior, and correct configuration. Zero Trust Shared Responsibility Changes Ownership As providers take on more operational responsibility, organizations may reduce infrastructure burden but must still understand which risks remain theirs. Cloud Governance Visibility Is a Security Requirement Virtual machines, containers, private cloud services, and managed security platforms all require monitoring and event visibility to support incident response. Security Monitoring Automation Improves Scale but Adds Risk Infrastructure automation, containers, Kubernetes-style deployment thinking, and policy automation can improve speed, but misconfiguration can scale quickly. Automation Risk Workflow Clarity Supports Security Clear user and system workflows reduce ambiguity, improve adoption, support process consistency, and help identify where authentication, authorization, and security controls should be placed. HCI / Process Cloud Migration Requires Planning Moving applications and data to cloud environments requires requirements gathering, vendor evaluation, RFI/RFP thinking, dependencies, and risk review. Migration Planning Security Strategy Must Be Communicated Technical security capabilities only matter if stakeholders understand risk, cost, compliance impact, implementation challenges, and expected business value. Executive Communication Capability-to-Evidence Map # Capability Evidence from IST 402 Status Cloud Infrastructure Hyper-V virtualization, OpenStack private cloud, compute resources, virtual networking, identity roles, Horizon dashboard access, and private cloud resource scaling. Completed Container Fundamentals Docker images, running containers, environment variables, file access, container networking, multi-container applications, and Docker Compose workflows. Completed Zero Trust / mTLS Concepts Certificate creation, certificate validation failures, registry certificate review, Docker registry access testing, mutual TLS for service access, and manual certificate verification. Completed Secure Cloud Configuration OpenSCAP review, SSH hardening, Wazuh monitoring, security profile updates, container event visibility, and secure architecture design. Completed Workflow Modeling Mapped user access workflow for Discord, including login, QR-code authentication, navigation, file sharing, voice call flow, settings, and logout confirmation. Completed Cloud Security Strategy SECaaS evaluation, CrowdStrike Falcon proposal, continuous monitoring, incident response, threat intelligence, compliance, and executive-facing security justification. Completed Cloud Governance Awareness Shared responsibility, provider-managed controls, automation tradeoffs, RFI planning, vendor support boundaries, and cloud migration planning. Completed What I Learned # This course reinforced several lessons that matter in cybersecurity and consulting work:\ncloud security starts with understanding infrastructure boundaries virtualization affects networking, resource allocation, recovery, and monitoring private cloud platforms require identity, compute, networking, and dashboard governance containers introduce new runtime and dependency risks certificate-based trust must be configured, validated, and tested mutual TLS can enforce stronger service-to-service authentication failed certificate validation is a useful security signal, not just an error secure configuration should be tested and monitored continuously user workflow modeling helps identify control points and user friction cloud migration requires requirements gathering and vendor evaluation shared responsibility must be clearly understood before moving workloads SECaaS can reduce operational burden but requires governance, SLAs, and oversight executive communication is a major part of successful technology adoption security strategy must connect technical controls to risk reduction and business value Professional Relevance # This project supports roles involving:\ncloud security cybersecurity analysis security operations ServiceNow SecOps consulting vulnerability management cloud migration support infrastructure security container security fundamentals zero trust architecture concepts certificate-based access control workflow and process mapping security governance executive-facing security communication It also supports my ServiceNow SecOps direction because cloud environments still require structured triage, ownership, remediation tracking, validation, exception handling, policy mapping, workflow clarity, and stakeholder communication.\nPortfolio-Safe Redaction Notes # This case study intentionally excludes:\nraw screenshots exact command history private lab credentials IP addressing details certificate material full lab submissions complete diagrams raw presentation files private student identifiers non-public course materials The purpose is to show cloud infrastructure, cloud security, zero trust, and workflow modeling understanding without publishing raw academic materials.\nRelated Portfolio Areas # Cloud Security # This work connects virtualization, containers, private cloud, certificate-based trust, mutual TLS, continuous monitoring, secure configuration, and Security-as-a-Service strategy.\nCloud Security\nServiceNow SecOps # Cloud environments still need vulnerability ownership, remediation tracking, security incident workflows, governance, validation, and clear process design.\nSecOps-Relevant\nSecurity Operations # Continuous monitoring, event review, configuration validation, certificate failure interpretation, and incident response are core security operations concerns.\nSOC-Relevant\nHCI and Workflow Design # The Discord workflow artifact supports user-flow thinking, process modeling, and designing systems that are understandable and navigable.\nHCI\nGRC / Vendor Risk # SECaaS adoption introduces shared responsibility, vendor dependency, compliance, data privacy, SLA, and governance concerns.\nGRC-Relevant\nNext Steps # This project can later be connected to:\na cloud security capability section a ServiceNow cloud vulnerability workflow concept a SECaaS vendor evaluation note a shared-responsibility risk matrix a container security checklist a cloud migration security checklist a zero trust / mTLS concept note a workflow modeling and HCI evidence section a ServiceNow IRM/GRC learning path For now, this page serves as the main portfolio-safe summary of my IST 402 emerging technologies, cloud infrastructure, cloud network security, workflow modeling, and SECaaS strategy work.\n","date":"5 June 2026","externalUrl":null,"permalink":"/projects/ist-402-cloud-virtualization-secaas-architecture/","section":"Projects","summary":"","title":"IST 402: Cloud Virtualization, Containers \u0026 SECaaS Architecture","type":"projects"},{"content":" GRC / Cyber Law Case Study\nThis portfolio-safe case study summarizes selected IST 432 Legal and Regulatory Environment of Information Science and Technology work focused on cyber law, privacy, governance, regulatory risk, digital rights, Fourth Amendment concerns, authorization boundaries, and compliance-aware security decision-making.\nCourse IST 432 Focus Cyber Law · Privacy · GRC · Digital Governance Content Type Redacted Academic Case Analysis Themes FISA · Patriot Act · CFAA · ACPA · Fourth Amendment · Privacy Publishing Level Portfolio-Safe / No Raw Submissions Professional Angle Governance, Risk, Compliance, and Security Policy Awareness Overview # IST 432 focused on the legal and regulatory environment surrounding information science and technology. The course connected cybersecurity, information systems, surveillance law, digital privacy, cybercrime, online platforms, intellectual property, and regulatory interpretation.\nFor my portfolio, this course is best framed as GRC-adjacent evidence. It shows that cybersecurity work does not exist only at the technical layer. Security decisions also involve law, policy, privacy, authorization, risk tolerance, organizational governance, and compliance boundaries.\nThis case study is not legal advice and does not present raw academic submissions. It summarizes portfolio-safe lessons from academic case briefings, group research, and cyber law analysis.\nWhy This Belongs in a Cybersecurity Portfolio # Security teams often need to understand more than tools and alerts.\nA cybersecurity professional may need to think about:\nwhether access was authorized whether monitoring creates privacy concerns whether data collection is proportional to a legitimate objective whether an organization has clearly defined access controls whether policies are specific enough to support enforcement whether digital platforms have enforceable terms whether cyber incidents create regulatory, legal, or reputational risk whether technical evidence can be translated into governance decisions IST 432 helped build that layer of thinking.\nFrom a GRC perspective, this work supports:\nprivacy risk awareness regulatory interpretation legal-risk communication policy and authorization boundaries cybercrime classification governance-aware security analysis digital rights and platform governance compliance-sensitive reporting Portfolio-Safe Publishing Approach # Security and privacy note: This page summarizes academic cyber law and GRC-related work without publishing raw group submissions, private student details, full legal briefs, complete academic answers, or private course materials.\nThis page intentionally avoids publishing:\nraw assignment files full case briefs private student identifiers complete group submissions professor-provided materials private academic records full legal analysis drafts non-public discussion details Instead, it presents:\nhigh-level case themes governance lessons risk interpretation privacy and compliance implications portfolio-safe summaries professional lessons learned Core GRC Themes # Governance # The coursework emphasized how laws, policies, courts, and organizational rules define what actions are authorized, prohibited, or subject to oversight.\nGovernance\nRisk # The case work required identifying legal, privacy, reputational, operational, and cybersecurity risks created by technology use, digital platforms, surveillance, and online behavior.\nRisk Analysis\nCompliance # The course connected information technology decisions to statutes, case law, constitutional concerns, access boundaries, intellectual property rules, and regulatory obligations.\nCompliance Awareness\nPrivacy # A recurring theme was the tension between security needs, investigative authority, metadata collection, digital privacy, and individual constitutional protections.\nPrivacy\nSelected Case and Research Areas # Topic Portfolio-Safe Summary GRC Angle FISA and the Patriot Act Group research examined surveillance authority, metadata collection, national security objectives, civil liberties, Fourth Amendment concerns, and emerging technologies such as AI predictive analytics. Privacy Governance Bulk Metadata Collection Research considered how metadata can reveal personal information and why collection scope, legal authority, oversight, and proportionality matter in security programs. Data Governance Fourth Amendment Analysis Case briefing work addressed searches, expectations of privacy, controlled delivery facts, warrant questions, and balancing law enforcement interests against individual privacy rights. Legal Risk CFAA Authorization Boundaries Case analysis addressed whether employee system access exceeded authorization and highlighted the importance of clearly defined access rules, revocation procedures, and policy boundaries. Access Governance Cybersquatting and Online Criticism ACPA-related case work examined domain name use, trademark interests, bad-faith intent to profit, consumer criticism, fair use, and online reputational risk. Digital Risk Digital Property and Platform Governance Case analysis involving virtual property and platform enforcement raised questions about digital assets, account control, platform terms, and dispute resolution. Platform Governance Cybercrime Scenario Analysis Scenario work covered identity theft, online auction fraud, and cyberstalking, connecting cybercrime concepts to real-world victim impact and legal classification. Cybercrime Risk Analysis Workflow # 1 Identify the Legal / Governance Question # Each case began by identifying the core issue: privacy, authorization, search authority, digital rights, cybersquatting, platform control, or cybercrime classification.\nIssue Spotting\n2 Summarize Facts and Stakeholders # The analysis considered who was involved, what actions occurred, what systems or data were implicated, and what harms or interests were at stake.\nFact Pattern\n3 Identify Applicable Law or Policy # The work connected facts to statutes, legal standards, constitutional concerns, platform rules, or access-control concepts.\nLegal Mapping\n4 Analyze Risk and Competing Interests # The case work required balancing security needs, privacy rights, business interests, platform control, reputational risk, and individual rights.\nRisk Analysis\n5 Explain the Decision or Outcome # The final step was translating the legal or regulatory reasoning into a clear explanation that could be understood by non-specialists.\nCommunication\nGRC Capability-to-Evidence Map # Capability Evidence from IST 432 Status Privacy Risk Analysis Analyzed surveillance, metadata collection, FISA, the Patriot Act, Fourth Amendment concerns, and privacy implications of emerging technologies. Completed Access Governance Reviewed authorization boundaries under CFAA-related case analysis and connected the outcome to the importance of clear access rules and revocation procedures. Completed Legal-Risk Communication Converted legal fact patterns into structured procedural history, facts, legal questions, decisions, rationale, and analysis. Completed Digital Governance Analyzed platform control, digital property, online speech, domain names, fair use, reputation risk, and intellectual property boundaries. Completed Cybercrime Awareness Mapped identity theft, online fraud, and cyberstalking scenarios to practical legal and security concerns. Completed Professional Lessons Learned # This course reinforced several lessons that matter in cybersecurity and GRC work:\ntechnical access should be supported by clear authorization rules security monitoring must be balanced against privacy expectations data collection scope matters metadata can create privacy and governance risk legal authority should be paired with oversight and proportionality platform policies can affect digital property and account control cybercrime analysis requires both technical and legal context governance decisions should be explainable to non-technical stakeholders compliance work depends on clear documentation and risk communication Connection to ServiceNow SecOps and Cybersecurity Work # IST 432 supports my broader cybersecurity portfolio because ServiceNow SecOps, Vulnerability Response, and cybersecurity operations are not only technical workflows.\nIn practical security environments, analysts and consultants often need to understand:\nwho owns the risk who is authorized to access a system what evidence supports a decision whether the organization has documented policy whether data handling creates privacy risk how to explain technical risk to business stakeholders how security operations connect to governance and compliance That makes this course useful supporting evidence for GRC-aware cybersecurity work.\nWhat This Demonstrates # This project demonstrates:\ncyber law awareness privacy risk analysis governance and compliance thinking access-control policy awareness Fourth Amendment and surveillance-risk awareness cybercrime scenario analysis digital platform governance awareness intellectual property and cybersquatting risk awareness structured case briefing professional writing and legal-risk communication ability to connect technology decisions to non-technical consequences Portfolio-Safe Redaction Notes # This case study intentionally excludes:\nraw case briefs full group submissions private student identifiers professor-provided course material full legal analysis drafts private academic records non-public discussion content The purpose is to show GRC-relevant reasoning and cyber law awareness without publishing raw academic work.\nRelated Portfolio Areas # Governance, Risk, and Compliance # This course supports the governance side of cybersecurity by connecting technical behavior to law, policy, oversight, privacy, and organizational accountability.\nGRC\nSecurity Operations # Security operations benefit from legal and governance awareness because analysts often handle evidence, access questions, privacy-sensitive data, and escalation decisions.\nSOC-Relevant\nServiceNow SecOps # ServiceNow security workflows often involve assignment ownership, policy-defined responsibilities, risk acceptance, evidence, remediation status, and auditable decisions.\nSecOps-Relevant\nPrivacy and Data Governance # FISA, the Patriot Act, metadata, surveillance, and emerging technology analysis support a privacy-aware cybersecurity perspective.\nPrivacy\nNext Steps # This project can later be connected to:\na GRC capability section a privacy and data governance page a ServiceNow GRC / IRM learning path a risk-register concept note a policy-to-control mapping example a vulnerability exception and risk acceptance workflow concept For now, this page serves as the main portfolio-safe summary of my IST 432 cyber law, privacy, and GRC-related academic work.\n","date":"5 June 2026","externalUrl":null,"permalink":"/projects/ist-432-cyber-law-privacy-grc-case-analysis/","section":"Projects","summary":"","title":"IST 432: Cyber Law, Privacy \u0026 GRC Case Analysis","type":"projects"},{"content":" Computer \u0026amp; Cyber Forensics Case Study\nThis portfolio-safe case study summarizes selected IST 454 Computer and Cyber Forensics work focused on forensic image creation, forensic image mounting, hash verification, Windows registry analysis, data carving, deleted file recovery, IoT forensics, and AI-assisted security/forensics research.\nCourse IST 454 Project Type Computer \u0026 Cyber Forensics Lab Evidence Focus Forensic Imaging · Registry Analysis · Data Carving · Reporting Tools / Platforms FTK Imager · WinHex · RegRipper · Registry Viewer · Kali Linux · dcfldd Research Angle AI Security Datasets · IoT Forensics · Multi-Source Evidence Publishing Level Portfolio-Safe / Partial Evidence / No Raw Images Published Overview # IST 454 focused on computer and cyber forensics. The available evidence from this course supports a portfolio-safe summary around digital evidence handling, forensic image creation, forensic image mounting, hash verification, registry analysis, deleted file recovery, data carving, and research into AI/IoT forensics.\nI do not currently have every original lab submission from this course. Because of that, this page is intentionally framed as selected lab evidence, not a complete course archive.\nThe strongest evidence available includes:\nWindows forensic image creation and mounting Kali Linux disk image creation and hashing MD5 and SHA256 hash comparison read-only image handling Windows registry hive recovery and analysis SAM, SYSTEM, and NTUSER registry review concepts RegRipper usage deleted image recovery deleted document recovery WinHex data carving file recovery by type group analysis of recovered documents and encrypted file indicators research on AI-based cybersecurity and forensics datasets discussion of IoT forensics, proprietary data formats, privacy, and investigation challenges This page is intentionally written as a sanitized case study. It does not publish raw forensic images, full screenshots, complete lab answers, raw recovered documents, private academic submissions, passwords, case artifacts, or full evidence files.\nWhy This Project Matters # Digital forensics is one of the clearest bridges between cybersecurity operations and evidence-based investigation.\nA useful forensic workflow needs to preserve evidence, maintain integrity, recover relevant artifacts, analyze system state, and communicate findings clearly.\nThis course supports several cybersecurity capabilities:\nevidence preservation forensic acquisition image mounting hash verification read-only analysis discipline registry analysis user activity review deleted file recovery data carving forensic reporting AI/IoT forensic research awareness This matters for security operations because incidents often require more than alert triage. Analysts may need to understand what happened on a system, what files existed, what was deleted, what devices were connected, what user activity occurred, and whether evidence was handled correctly.\nPortfolio-Safe Publishing Approach # Security and privacy note: This page summarizes forensic lab evidence without publishing raw forensic images, recovered files, complete reports, passwords, full screenshots, private student identifiers, or detailed evidence artifacts.\nThis page excludes:\nraw forensic images mounted disk image contents full recovered files recovered images or documents registry hive files exact lab passwords private screenshots full group submissions raw academic answers private course materials complete step-by-step instructions Instead, it presents:\nforensic workflows tools used evidence categories portfolio-safe technical summaries professional lessons learned relevance to incident response and security operations Evidence-Based Scope # Because not every lab file is available, this page uses a conservative evidence scope.\nAvailable Evidence What It Supports Confidence Windows Image Creation and Mounting Lab Supports forensic image creation, E01 image output, verification, mounting, and read-only forensic access using FTK Imager. Strong Kali Linux Image Creation and Hashing Lab Supports Linux partition identification, dcfldd-based disk imaging, MD5/SHA256 hash generation, read-only image handling, and hash comparison for integrity verification. Strong Windows Registry Analysis Lab Supports registry hive recovery and analysis, including SAM, SYSTEM, USBSTOR, NTUSER.DAT, Registry Viewer, and RegRipper-based user activity review. Strong Windows Data Carving Lab Supports forensic image mounting, WinHex-based recovery by type, deleted image recovery, deleted document recovery, and output organization. Strong Group Lab 5 Evidence Supports applied document recovery, repeated content identification, missing file reasoning, encrypted file observation, and analysis using FTK/WinHex outputs. Moderate AI / IoT Forensics Research Essay Supports research into AI-based security datasets, heterogeneous telemetry sources, IoT forensics, privacy issues, intrusion detection, digital forensics, and AI-assisted security analysis. Strong Forensic Workflow Map # 1 Identify and Preserve Evidence # Forensic work began with identifying disks, partitions, evidence sources, and target images while avoiding unnecessary alteration of original evidence.\nPreservation\n2 Create Forensic Images # Created forensic images using FTK Imager and dcfldd-style workflows, including compressed forensic image formats and disk image output.\nAcquisition\n3 Verify Integrity # Used hash generation and hash comparison, including MD5 and SHA256-style validation, to confirm image integrity and support evidence reliability.\nHash Verification\n4 Mount Images Read-Only # Mounted forensic images read-only so analysis could be performed without modifying the evidence source.\nRead-Only Analysis\n5 Recover and Analyze Artifacts # Recovered registry hives, reviewed user/system registry data, carved deleted images and documents, and examined recovered artifacts.\nArtifact Recovery\n6 Report Findings # Converted forensic observations into portfolio-safe findings, including recovered file categories, registry analysis relevance, and research implications.\nReporting\nForensic Imaging Evidence # The course evidence includes both Windows and Linux imaging workflows.\nThe Windows imaging lab involved:\nlaunching FTK Imager creating a forensic image selecting evidence source type choosing an E01-style image output entering case/evidence/examiner metadata saving the image to a case folder verifying the image mounting the forensic image selecting a drive letter confirming read-only mounting preparing the mounted image for later analysis The Kali Linux imaging lab involved:\nidentifying partitions selecting a target partition creating a disk image using dcfldd generating MD5 and SHA256 hash logs during imaging setting the resulting image to read-only hashing the original source for comparison discussing hash comparison and evidence integrity The key lesson is that forensic analysis should be performed on an acquired image rather than directly on original evidence, and that hashing supports evidence integrity.\nRegistry Analysis Evidence # The registry analysis lab supported Windows forensic analysis concepts.\nThe available evidence includes work around:\nrecovering registry hives exporting SAM and SYSTEM files analyzing SAM with Registry Viewer reviewing user account information analyzing SYSTEM registry data identifying connected USB device artifacts through USBSTOR recovering NTUSER.DAT using RegRipper to analyze NTUSER data searching for recently opened files using registry artifacts to infer user or system activity This is relevant because the Windows registry can contain important evidence about user behavior, connected devices, account information, system configuration, and recent activity.\nData Carving Evidence # The data carving lab focused on recovering deleted files from a mounted forensic image.\nThe available evidence includes:\nmounting an image with FTK Imager opening the physical storage device in WinHex recovering deleted images by file type creating output folders for carved pictures recovering deleted documents by file type using free cluster and sector boundary search settings reviewing recovered output organizing recovery results This supports a practical understanding of deleted file recovery and forensic artifact extraction.\nData recovery from a mounted forensic image # The data recovery lab focused on a “Company Secrets” case involving recovered documents and file artifacts which needed to be investigated, and certain information had to be extracted.\nThe available evidence supports:\nrecovered document review identifying repeated content recognizing missing file numbers identifying a file with mRNA-related content observing encrypted file indicators noting an OLE2 encrypted file type connecting recovered artifacts to FTK and WinHex outputs AI and IoT Forensics Research # The research essay focused on AI as it relates to cybersecurity and forensics.\nThe essay discussed:\nAI-based security applications TON_IoT Windows datasets heterogeneous telemetry Windows and Linux operating system data network traffic data IoT service data intrusion detection threat intelligence privacy preservation digital forensics limitations of homogeneous datasets multi-faceted attacks overfitting and incomplete feature sets labeled datasets with ground truth correlation analysis energy and scalability considerations for AI systems This research angle matters because modern forensics increasingly depends on large-scale, multi-source evidence. IoT, cloud, endpoint, and network telemetry create both opportunities and challenges for investigators.\nIoT Forensics Discussion Evidence # The available discussion work addressed IoT forensics and the difficulty of investigating connected devices.\nThemes included:\nIoT devices generating large volumes of data cloud-based device data proprietary vendor formats multi-tenant cloud infrastructure multi-jurisdictional evidence concerns end-to-end encryption privacy of smart car occupants insecure or poorly secured connected devices use of tools such as Splunk to aggregate different evidence sources need for broader visibility across logs, APIs, files, directories, and network events This supports the broader forensic theme that modern investigations often require multi-source evidence handling and privacy-aware analysis.\nTools and Techniques Referenced # Tool / Technique Forensic Purpose Evidence Type FTK Imager Forensic image creation, evidence source selection, E01-style output, verification, image mounting, and read-only access. Imaging dcfldd Linux disk image creation with hash generation and error-handling options during acquisition. Acquisition MD5 / SHA256 Hashing Evidence integrity validation through hash generation and comparison. Integrity Registry Viewer SAM and SYSTEM registry hive analysis for account and system artifact review. Registry RegRipper NTUSER.DAT analysis and user activity artifact extraction. User Activity WinHex Opening mounted forensic images, recovering deleted images and documents, and carving files by type. Data Carving Splunk / Multi-Source Telemetry Concepts Discussion of aggregating logs, files, directories, network events, and APIs for broader forensic and security visibility. Telemetry Capability-to-Evidence Map # Capability Evidence from IST 454 Status Forensic Acquisition Created Windows and Linux forensic images, used FTK Imager and dcfldd-style workflows, and reviewed image output and read-only handling. Evidence Available Evidence Integrity Generated and compared MD5 and SHA256 hashes to validate forensic image integrity. Evidence Available Registry Analysis Recovered and analyzed SAM, SYSTEM, and NTUSER registry hives using Registry Viewer and RegRipper-style workflows. Evidence Available Data Carving Recovered deleted images and documents from a mounted forensic image using WinHex and file recovery by type. Evidence Available Artifact Review Reviewed recovered document content, repeated files, missing file references, encrypted file indicators, and file-type observations. Supporting Evidence AI / IoT Forensics Research Researched AI-based security datasets, IoT telemetry, heterogeneous data sources, privacy preservation, IDS, threat intelligence, and forensic investigation challenges. Research Evidence Professional Lessons Learned # This course reinforced several lessons that matter for cybersecurity and incident response:\nevidence should be acquired and analyzed carefully, not altered directly forensic images should be mounted read-only when possible hashing supports evidence integrity and repeatability deleted files may still be recoverable through data carving registry artifacts can reveal user activity, connected devices, and system state forensic investigation often requires multiple tools modern investigations increasingly involve IoT, cloud, and large-scale telemetry proprietary data formats and encryption can complicate analysis AI datasets may help security teams, but data quality and feature completeness matter forensic reporting should clearly separate evidence, inference, and uncertainty Professional Relevance # This project supports roles involving:\ncybersecurity analysis digital forensics incident response security operations malware investigation endpoint investigation GRC-aware evidence handling forensic reporting IoT security awareness AI-assisted security research It also complements my CYBER 440 capstone work. CYBER 440 demonstrates a broader simulated incident investigation; IST 454 adds dedicated computer and cyber forensics evidence around image acquisition, registry analysis, deleted file recovery, and forensic research.\nDifference from CYBER 440 # IST 454 and CYBER 440 overlap, but they show different strengths.\nCourse Main Portfolio Angle Best Evidence Type IST 454 Forensic imaging, hash verification, registry analysis, deleted file recovery, data carving, IoT forensics, and AI-assisted forensic research. Digital Forensics CYBER 440 Simulated incident response capstone involving network evidence, forensic images, memory artifacts, logs, timeline development, and remediation planning. IR Capstone Together, they show both focused forensic technique exposure and broader incident investigation workflow.\nPortfolio-Safe Redaction Notes # This case study intentionally excludes:\nraw forensic images mounted image contents recovered documents and images registry hive files exact passwords full screenshots full lab submissions complete group reports private academic records step-by-step lab procedures complete source evidence The purpose is to show digital forensics knowledge and investigation workflow without exposing raw evidence or academic materials.\nRelated Portfolio Areas # Digital Forensics # This work supports forensic acquisition, evidence integrity, image mounting, registry analysis, deleted file recovery, and artifact review.\nForensics\nIncident Response # Forensic evidence handling supports incident triage, root-cause analysis, timeline reconstruction, and evidence-based reporting.\nIR-Relevant\nSecurity Operations # Security analysts benefit from understanding file recovery, registry artifacts, logs, telemetry, and endpoint evidence.\nSOC-Relevant\nAI and IoT Forensics # The research work connects forensic thinking to AI datasets, IoT telemetry, privacy, data volume, and multi-source investigation challenges.\nEmerging Forensics\nNext Steps # This project can later be connected to:\nthe cybersecurity analyst review path the digital forensics capability section the CYBER 440 capstone page an incident-response evidence lifecycle diagram a forensic imaging checklist a registry analysis concept note a data carving concept note an AI/IoT forensics research section For now, this page serves as the main portfolio-safe summary of my IST 454 computer and cyber forensics evidence.\n","date":"5 June 2026","externalUrl":null,"permalink":"/projects/ist-454-computer-cyber-forensics-lab-evidence/","section":"Projects","summary":"","title":"IST 454: Computer \u0026 Cyber Forensics Lab Evidence","type":"projects"},{"content":" Security \u0026amp; Risk Management Case Study\nThis portfolio-safe case study summarizes selected IST 456 Security and Risk Management work focused on SIEM-style investigation, ransomware response, compromised credentials, data exfiltration, security policy analysis, ISO/IEC 27000 concepts, contingency planning, compliance, and risk-based security recommendations.\nCourse IST 456 Project Type Security \u0026 Risk Management Lab Collection Platform Enigma Glass Security Lab Environment Focus SIEM Investigation · Risk Management · GRC · Incident Response Themes Ransomware · Credential Compromise · Data Exfiltration · Policy · Compliance Publishing Level Portfolio-Safe / No Raw Lab Data Published Overview # IST 456 focused on security and risk management from both a technical and governance perspective.\nThe course included hands-on lab work in the Enigma Glass security environment, written analysis, executive-style summaries, and group work around security policies, standards, and contingency planning.\nThe strongest portfolio angle is that this course connects technical security investigation with security management and GRC thinking.\nThe work covered:\nSIEM-style event review ransomware outbreak analysis compromised credential investigation malicious document activity failed and successful logon review data exfiltration analysis FTP-based file transfer risk threat intelligence reporting risk mitigation recommendations security policy analysis acceptable use and information assurance policy review ISO/IEC 27000-series standards contingency planning for physical and cyber incidents compliance with personal information breach notification requirements banking threats and vulnerabilities insider threat concerns MFA, least privilege, segmentation, training, monitoring, and backup recommendations This page is intentionally written as a portfolio-safe summary. It does not publish raw lab screenshots, full answers, private lab data, user accounts, internal simulated environment details, or complete group submissions.\nWhy This Project Matters # Security and risk management sits between technical investigation and business decision-making.\nA security analyst may identify suspicious activity, but a security manager or consultant must also ask:\nWhat is the risk? What assets are affected? What controls failed? What should be contained first? Which policies apply? Which stakeholders need to know? Which compliance obligations may be triggered? What should be improved to prevent recurrence? How should the organization document and communicate the event? IST 456 helped connect those questions to practical labs and written security management work.\nThis makes the course relevant to ServiceNow SecOps, Vulnerability Response, security operations, incident response, GRC, risk management, and cybersecurity consulting.\nPortfolio-Safe Publishing Approach # Security note: This case study summarizes security management and lab work without publishing raw lab screenshots, simulated user records, complete reports, private student identifiers, environment-specific details, or full academic submissions.\nThis page excludes:\nraw Enigma Glass screenshots full lab answer sheets simulated user account details exact environment data complete group submissions private student identifiers complete policy writeups full academic answers raw threat intelligence report templates private course materials Instead, it presents:\nsecurity investigation themes risk management lessons portfolio-safe evidence summaries policy and standards concepts GRC and compliance takeaways professional recommendations relevance to security operations and ServiceNow SecOps Major Workstreams # Enigma Glass SIEM Labs # Used an Enigma Glass lab environment to investigate ransomware, compromised credentials, quarantine failures, failed logons, suspicious files, and data exfiltration events.\nSIEM Investigation\nRansomware Outbreak Analysis # Reviewed threat detection events, quarantine failures, suspicious executable behavior, WannaCry-style ransomware indicators, SMB/MS17-010 risk, and hardening recommendations.\nRansomware\nCompromised Credentials # Investigated abnormal account activity, suspicious logons, malicious document activity, failed authentication, successful suspicious login, credential theft risk, and remediation steps.\nCredential Risk\nData Exfiltration # Analyzed suspected data exfiltration involving FTP file download behavior, external destination concerns, possible credential compromise, insider threat questions, and zero trust recommendations.\nExfiltration\nSecurity Policy and Standards # Reviewed security policies, acceptable use, information assurance, privacy, HIPAA-related policy concepts, ISO/IEC 27000-series standards, and mid-size organization applicability.\nGRC\nContingency Planning # Developed contingency planning concepts for incidents such as power failure, denial-of-service, fire, burst pipe, remote work, employee communication, and business continuity.\nContingency\nEnigma Glass Lab Evidence # Lab / Scenario Portfolio-Safe Summary Focus Ransomware Outbreak Reviewed threat detection events, quarantine failures, suspicious file names, WannaCry-style ransomware behavior, SMB exposure, patching, segmentation, and user alert recommendations. Ransomware Compromised Credentials Investigated abnormal user activity, malicious document events, failed logon activity, successful suspicious login, credential harvesting risk, account remediation, and MFA recommendations. Identity Risk Phishing / Malicious PDF Reviewed phishing-style activity involving malicious document download, sandbox-style research, credential theft risk, lateral movement concerns, and employee awareness recommendations. Phishing Data Exfiltration Analyzed suspected FTP-based data exfiltration, AV events, external transfer timing, insider threat or credential compromise questions, investigation next steps, and blocking/zero trust recommendations. Exfiltration Threat Intelligence Reporting Converted findings into threat research notes and remediation recommendations intended for management or executive-style briefings. Reporting Security Management and GRC Evidence # Topic Portfolio-Safe Summary GRC Angle Security Policies and Standards Group work reviewed university-style information assurance, acceptable use, privacy, HIPAA-related policy concepts, and policy revision history. Policy ISO/IEC 27000 Series Analyzed ISO/IEC 27001 and related standards as an information security management system framework for protecting confidentiality, integrity, and availability. Standards Policy and Compliance Executive Summary Reviewed Pennsylvania Breach of Personal Information Notification Act considerations, PII exposure, university departments handling sensitive data, and control recommendations such as MFA and incident response planning. Compliance Banking Threats and Vulnerabilities Analyzed mobile banking vulnerabilities, malware, phishing, denial-of-service, insider threat, weak authentication, unpatched systems, and risk mitigation strategy. Risk Analysis Contingency Planning Developed planning concepts for incidents such as power failure, denial-of-service attacks, fire, burst water pipe, business continuity, remote work, employee communication, and recovery procedures. Resilience Technical Investigation Workflow # 1 Review Security Events # Started with SIEM-style dashboards and event records to identify affected users, affected workstations, threat detections, failed quarantines, suspicious files, and abnormal activity.\nEvent Review\n2 Identify Indicators and Patterns # Looked for suspicious filenames, malicious document activity, logon anomalies, failed authentication, successful suspicious access, external transfers, and unusual timing.\nIndicator Review\n3 Research the Threat # Used threat research to connect events to ransomware, phishing, malicious documents, credential theft, data exfiltration, and known attack behaviors.\nThreat Research\n4 Assess Business Risk # Translated technical findings into risks such as credential compromise, lateral movement, ransomware spread, data theft, operational disruption, and compliance exposure.\nRisk Analysis\n5 Recommend Remediation # Recommended containment, password resets, MFA, patching, backup validation, segmentation, employee training, monitoring, zero trust, and incident response plan improvement.\nRemediation\n6 Communicate Findings # Summarized findings in threat intelligence and management-facing language suitable for escalation, reporting, and decision support.\nReporting\nRansomware Response Themes # The ransomware lab focused on a WannaCry-style scenario.\nThe analysis involved:\nreviewing threat detection events identifying affected hostnames reviewing quarantine failure events connecting suspicious file activity to ransomware behavior researching WannaCry-style malware behavior understanding Windows operating system impact identifying SMB/MS17-010 as a key risk area recommending patching recommending disabling unnecessary SMB exposure recommending spam filtering recommending network segmentation recommending employee awareness alerts The key security management lesson was that ransomware response requires both immediate containment and longer-term defensive hardening.\nCompromised Credential Themes # The compromised credential lab focused on suspicious account activity.\nThe analysis involved:\nreviewing workstation events identifying quarantine failure counts correlating suspicious document activity with abnormal account behavior reviewing failed and successful logon events considering geographic anomalies interpreting malicious document infection as a possible credential compromise source recommending workstation isolation recommending credential resets recommending MFA recommending activity log review recommending malware removal or system restoration recommending backups and SIEM monitoring recommending least privilege, segmentation, training, and penetration testing The key lesson was that identity compromise can become a gateway to broader organizational compromise.\nData Exfiltration Themes # The data exfiltration lab focused on suspicious outbound data movement.\nThe analysis involved:\nreviewing cloud IOC indicators reviewing antivirus events by user reviewing network activity identifying an FTP file download event considering credential compromise or insider threat possibilities recognizing external destination risk recommending log review and audit activity recommending unauthorized connection removal recommending IP blocking where appropriate recommending zero trust principles recommending FTP restrictions recommending employee training and access control review The key security management lesson was that exfiltration investigation requires both technical evidence and business context.\nSecurity Policy and Standards Themes # The group policy and standards work connected security management to formal governance.\nThe work covered:\ninformation assurance and IT security policy acceptable use policy privacy policy HIPAA-related policy concepts data classification approved IT services access requirements security responsibility matrices information security modernization policy revision history ISO/IEC 27001 and related ISO/IEC 27000-series guidance information security management systems confidentiality, integrity, and availability risk assessment control selection compliance support certification and stakeholder confidence This supports a GRC-aware cybersecurity perspective because technical controls need policy support and management accountability.\nContingency Planning Themes # The contingency planning work focused on preparing for both cyber and physical incidents affecting a business.\nThe planning addressed:\npower failure denial-of-service attacks fire burst water pipe before/during/after incident responsibilities IT department responsibilities user responsibilities UPS and generator planning hot-site or remote-work options emergency contact information documentation review business continuity customer data protection operational recovery lessons learned This supports security and risk management because not all disruptions are purely cyber incidents. Physical failures, outages, facilities incidents, and cyberattacks can all affect availability and business continuity.\nControl Recommendations # Across the course, recurring control recommendations included:\nControl Area How It Appeared in the Work Risk Reduced Multi-Factor Authentication Recommended for credential compromise, account protection, and compliance-oriented improvement. Identity Risk Patch Management Recommended for ransomware hardening, especially where known vulnerabilities could support worm-like spread. Vulnerability Risk Network Segmentation Recommended to limit lateral movement and reduce ransomware spread across an organization. Lateral Movement SIEM and Monitoring Used in Enigma Glass labs and recommended for better visibility into suspicious activity and investigations. Detection Least Privilege Recommended to reduce privilege escalation and limit the impact of compromised credentials. Access Control Backups and Recovery Recommended for ransomware recovery, system restoration, and continuity planning. Recovery Security Awareness Training Recommended for phishing, malicious documents, ransomware prevention, and user behavior improvement. Human Risk Zero Trust Principles Recommended in the data exfiltration context to reduce implicit trust and enforce stronger access controls. Data Protection Capability-to-Evidence Map # Capability Evidence from IST 456 Status SIEM Investigation Used Enigma Glass lab workflows to review ransomware, compromised credentials, failed logons, quarantine failures, suspicious files, and data exfiltration events. Completed Threat Research Connected observed events to ransomware, phishing, malicious documents, credential theft, FTP data exfiltration, and known attack behavior. Completed Risk Management Translated technical activity into business risk involving confidentiality, integrity, availability, compliance, identity risk, and operational disruption. Completed GRC and Policy Analysis Reviewed security policies, acceptable use, privacy, HIPAA-related policy concepts, ISO/IEC 27000-series standards, and compliance considerations. Completed Contingency Planning Developed incident response and continuity planning concepts for power failure, DoS, fire, burst pipe, remote work, user responsibilities, and recovery activities. Completed Executive Communication Created written analysis and executive-style summaries connecting technical risk, compliance, controls, and organizational impact. Completed What I Learned # This course reinforced several security management lessons:\nSIEM alerts need context before they become actionable incidents quarantine failure can be as important as threat detection ransomware response requires patching, segmentation, backups, and communication compromised credentials can lead to broader lateral movement and privilege escalation risk data exfiltration analysis requires business context and transfer-protocol review phishing and malicious documents remain major identity and endpoint risks MFA, least privilege, monitoring, backups, and training are recurring defensive controls security policy gives technical controls organizational authority ISO-style standards support structured information security management contingency planning must address both cyber and physical disruptions executive communication is part of security management, not an afterthought Professional Relevance # This project supports roles involving:\ncybersecurity analysis security operations ServiceNow SecOps consulting vulnerability management incident response GRC and risk management compliance support SIEM investigation executive reporting contingency planning security policy support It is especially relevant to ServiceNow SecOps because security risk management requires structured triage, assignment ownership, remediation tracking, control recommendations, documentation, validation, and stakeholder communication.\nRelationship to Other Portfolio Projects # IST 456 complements several other portfolio areas.\nRelated Project How It Connects Angle CYBER 342W CYBER 342W focuses more deeply on incident response planning, NIST lifecycle, CSIRT, DR/BC, and communication strategy. IR Planning CYBER 440 CYBER 440 focuses on hands-on capstone investigation, forensic images, network evidence, memory analysis, logs, and remediation reporting. IR / Forensics IST 432 IST 432 focuses on cyber law, privacy, governance, legal risk, and regulatory interpretation. Cyber Law / GRC ServiceNow SecOps Lab Hub ServiceNow SecOps connects these risk and response ideas to workflow, ownership, remediation tracking, validation, and closure. SecOps Workflow Portfolio-Safe Redaction Notes # This case study intentionally excludes:\nraw lab screenshots complete lab answers full group submissions simulated user records exact Enigma Glass environment details private student identifiers complete policy writeups raw threat intelligence templates private course materials The goal is to show security management, SIEM investigation, policy, risk, and GRC-related reasoning without exposing raw academic work.\nRelated Portfolio Areas # Security Operations # The Enigma Glass labs support SOC-style investigation, event review, threat detection, quarantine failure review, identity risk, and exfiltration analysis.\nSOC-Relevant\nRisk Management # The course connects threats and vulnerabilities to business risk, compliance obligations, policy, controls, and recovery planning.\nRisk Management\nServiceNow SecOps # The work maps naturally to SecOps concepts such as triage, prioritization, assignment, remediation, risk communication, and closure.\nSecOps-Relevant\nGRC and Compliance # Policy analysis, ISO/IEC 27000-series work, breach notification analysis, and contingency planning support a GRC-aware cybersecurity perspective.\nGRC\nNext Steps # This project can later be connected to:\na GRC capability section a security risk management review path a ServiceNow SecOps risk-to-remediation workflow a ransomware triage checklist a compromised credential triage checklist a data exfiltration investigation checklist a policy-to-control mapping page a contingency planning / business continuity section For now, this page serves as the main portfolio-safe summary of my IST 456 Security and Risk Management work.\n","date":"5 June 2026","externalUrl":null,"permalink":"/projects/ist-456-security-risk-management-enigma-glass-labs/","section":"Projects","summary":"","title":"IST 456: Security \u0026 Risk Management with Enigma Glass Labs","type":"projects"},{"content":" Academic Internship / Professional Experience\nThis portfolio-safe case study summarizes my IST 495 internship experience as a Research Intern with Penn State University’s College of Information Sciences and Technology, where I contributed to networking lab modernization, technical research, instructional improvement, lab validation, rubric development, team collaboration, and supervisor-facing project updates.\nCourse IST 495 Organization Penn State University · College of IST Role Research Intern Focus Networking Lab Modernization · Technical Documentation · QA Testing Delivery Model Remote / Team-Based Academic Technology Support Publishing Level Portfolio-Safe / No Internal Lab Materials Published Overview # IST 495 was my academic internship experience with Penn State University’s College of Information Sciences and Technology.\nThe internship focused on helping improve and modernize networking course labs for future IST students. The work involved researching networking technologies, reviewing existing lab materials, improving lab consistency, making instructions clearer, creating new questions and challenges, developing rubrics, testing labs in a controlled environment, collaborating with teammates, and communicating progress to a supervisor.\nThis page is intentionally written as a portfolio-safe professional experience summary. It does not publish internal lab materials, full lab instructions, private course content, supervisor details, team communications, or unpublished academic resources.\nWhy This Experience Matters # This internship is important because it shows professional experience inside Penn State’s College of IST, not only coursework.\nThe role required more than completing assignments. It involved contributing to instructional material that other students would later use, working as part of a team, researching emerging networking technologies, testing labs, documenting improvements, and communicating progress clearly.\nFrom a cybersecurity portfolio perspective, this experience supports:\nnetworking fundamentals technical documentation lab validation controlled testing instructional design teamwork supervisor communication professional accountability problem solving under uncertainty continuous learning preparation for cybersecurity and OT/ICS interests It also helped shape my longer-term interest in operational technology and cybersecurity, especially because networking knowledge is foundational to security operations, incident response, forensics, vulnerability management, and industrial security.\nPortfolio-Safe Publishing Approach # Privacy and academic integrity note: This page summarizes the internship experience without publishing internal lab instructions, supervisor communications, unpublished course materials, private team details, or controlled lab content.\nThis page excludes:\ninternal Penn State lab instructions unpublished course materials private supervisor communications private team discussions exact lab solution details internal rubrics controlled lab artifacts private student or staff identifiers proprietary instructional content Instead, it presents:\nrole summary responsibilities workflow skills demonstrated professional lessons learned cybersecurity relevance portfolio-safe outcomes Internship Scope # The internship centered on modernizing and improving networking labs.\nKey responsibilities included:\nreviewing existing networking lab materials researching newer or more relevant networking technologies identifying areas where lab instructions could be improved making lab instructions more uniform helping create clearer and more concise documentation developing new questions and challenges contributing to custom rubric development testing labs in a controlled environment identifying potential issues during validation collaborating with teammates participating in team discussions providing updates to the supervisor balancing weekly deliverables and deadlines The work supported future students by improving the quality, consistency, and clarity of networking lab experiences.\nMajor Workstreams # Networking Lab Modernization # Reviewed and improved existing networking lab materials to better align with updated technologies, clearer instructions, and more realistic networking concepts.\nNetworking\nTechnical Research # Performed research into emerging networking technologies and lab requirements so the team could improve course material with stronger technical context.\nResearch\nTechnical Documentation # Improved lab instructions for clarity, consistency, structure, and student usability.\nDocumentation\nLab Validation # Tested labs in a controlled environment to identify potential issues before future students used the material.\nQA Testing\nRubric and Challenge Development # Helped create new questions, challenges, and rubric elements to support student learning and assessment.\nInstructional Design\nTeam Collaboration # Worked with teammates and supervisor guidance to coordinate responsibilities, brainstorm improvements, and deliver weekly progress.\nTeamwork\nProfessional Workflow # 1 Review Existing Lab Material # Started by reviewing current networking labs and identifying where instructions, structure, or technical content could be improved.\nReview\n2 Research Networking Technologies # Performed technical research into networking tools, requirements, and updated concepts needed to improve the labs.\nResearch\n3 Improve Instructions and Structure # Modified lab materials to make instructions more uniform, concise, and easier for students to follow.\nDocumentation\n4 Add Questions, Challenges, and Rubrics # Helped create new student-facing questions, challenges, and custom rubric elements to support assessment and learning outcomes.\nInstructional Design\n5 Test Labs in a Controlled Environment # Validated lab behavior by testing materials in a controlled environment and identifying potential issues before future use.\nValidation\n6 Communicate Progress # Provided updates through team discussions and supervisor-facing communication, helping keep the project organized and aligned.\nCommunication\nKey Contributions # Contribution Portfolio-Safe Summary Skill Area Lab Review and Improvement Analyzed existing networking labs and helped improve their structure, clarity, consistency, and instructional flow. Documentation Emerging Technology Research Researched networking technologies and requirements to support modernization of course lab material. Research Question and Challenge Design Contributed to new questions and challenge elements designed to make labs more engaging and useful for future students. Instructional Design Rubric Development Helped develop custom rubric components to support evaluation of student lab work. Assessment Controlled Lab Testing Tested labs in a controlled environment to identify issues and validate that future students would have a smoother learning experience. QA Testing Team Facilitation Participated in and helped facilitate team discussions to keep responsibilities clear and support shared understanding. Collaboration Supervisor Communication Provided progress updates and participated in supervisor-facing project discussions. Professional Communication Skills Demonstrated # Skill Evidence from IST 495 Status Networking Foundations Worked with networking course lab material and researched technical requirements for updated networking exercises. Demonstrated Technical Documentation Improved lab instructions for consistency, clarity, concision, and student usability. Demonstrated Quality Assurance / Lab Validation Tested labs in a controlled environment and identified potential underlying issues. Demonstrated Problem Solving Worked through increasingly difficult lab modernization tasks and researched unfamiliar tools and requirements. Demonstrated Team Collaboration Worked with teammates to divide responsibilities, brainstorm improvements, and deliver weekly progress. Demonstrated Professional Communication Presented updates during weekly meetings and communicated project details with teammates and supervisor. Demonstrated Time Management Balanced weekly deliverables, morning meetings, ongoing research, and lab testing responsibilities. Demonstrated Challenges and Growth # The most challenging part of the internship came later in the project, when the team worked on a more difficult lab that required deeper research and problem solving.\nThat experience required:\nlearning unfamiliar tools and requirements researching more advanced networking concepts adapting when the solution was not immediately clear working through repetitive technical tasks balancing progress against time constraints collaborating with teammates under deadline pressure communicating progress and roadblocks clearly The experience helped build resilience, patience, and confidence when facing technical ambiguity.\nProfessional Development # This internship helped me grow professionally in several ways.\nIt reinforced the importance of:\npunctuality daily meetings communication discipline clear project updates teamwork supervisor alignment time management confidence under uncertainty continuous learning professional accountability It also helped me understand how technical work can support education. Improving a lab is not just about making a file work. It is about helping future students learn more effectively.\nConnection to Cybersecurity and OT/ICS # Although the internship was focused on networking lab development, it strongly supports my cybersecurity direction.\nNetworking is foundational to:\nsecurity operations vulnerability management incident response traffic analysis digital forensics cloud security OT/ICS security ServiceNow SecOps workflows The internship also influenced my interest in operational technology cybersecurity. The experience helped me see how networking knowledge connects to industrial and operational environments, especially where systems, infrastructure, uptime, and cybersecurity intersect.\nRelationship to Other Portfolio Work # Related Area How IST 495 Supports It Connection CYBER 362 Networking lab development supports later packet analysis, traffic review, and anomaly detection work. Network Analysis SRA 221 Networking foundations support early information security labs involving Wireshark, OpenVPN, pfSense, and service discovery. Security Foundations CYBER 440 Incident response and forensic investigation depend on understanding network behavior and system communication. IR / Forensics OT/ICS Security Networking concepts are central to operational technology environments, segmentation, availability, and cyber-physical risk. OT/ICS ServiceNow SecOps Technical documentation, process clarity, testing, and stakeholder communication map directly to SecOps implementation work. SecOps Workflow What I Learned # This internship reinforced several important lessons:\ntechnical documentation must be clear enough for future users lab instructions should be tested, not assumed to work networking knowledge supports cybersecurity and infrastructure work research is necessary when requirements are unclear teamwork improves technical delivery supervisor communication keeps projects aligned controlled testing reveals hidden issues rubrics and questions affect how students learn professional growth comes from working through ambiguity consistent communication and time management matter in technical projects Professional Relevance # This internship supports roles and tasks involving:\ncybersecurity analysis networking fundamentals ServiceNow SecOps consulting technical documentation lab validation QA testing training material development stakeholder communication team collaboration instructional technology OT/ICS security interest security operations readiness It is especially relevant to consulting because consulting work often requires translating technical ideas into clear documentation, validating workflows, communicating with stakeholders, and improving processes for other users.\nPortfolio-Safe Redaction Notes # This case study intentionally excludes:\ninternal lab instructions unpublished course materials private supervisor communications private team discussions complete rubrics lab solution details controlled lab artifacts private student or staff identifiers proprietary instructional content The goal is to show internship responsibilities, professional growth, technical documentation, and networking-lab modernization experience without publishing internal academic materials.\nRelated Portfolio Areas # Professional Experience # This internship provides real organizational experience with Penn State College of IST, team collaboration, deliverables, supervisor updates, and technical work.\nInternship\nNetworking Foundations # The work strengthened networking knowledge, which supports cybersecurity analysis, traffic analysis, forensics, and OT/ICS security.\nNetworking\nTechnical Documentation # The internship involved improving lab instructions, clarity, consistency, questions, challenges, and rubrics.\nDocumentation\nServiceNow SecOps # Process clarity, workflow validation, stakeholder communication, and documentation are directly relevant to ServiceNow implementation work.\nSecOps-Relevant\nNext Steps # This project can later be connected to:\nthe Resume page the About page the Professional Experience section the networking/security foundations capability section the OT/ICS security interest narrative the ServiceNow SecOps consulting communication narrative the project gallery as a supporting professional experience item For now, this page serves as the main portfolio-safe summary of my IST 495 Penn State College of IST Network Lab Development Internship.\n","date":"5 June 2026","externalUrl":null,"permalink":"/projects/ist-495-network-lab-development-internship/","section":"Projects","summary":"","title":"IST 495: Penn State College of IST Network Lab Development Internship","type":"projects"},{"content":"","date":"5 June 2026","externalUrl":null,"permalink":"/tags/java/","section":"Tags","summary":"","title":"Java","type":"tags"},{"content":"","date":"5 June 2026","externalUrl":null,"permalink":"/tags/lab-development/","section":"Tags","summary":"","title":"Lab Development","type":"tags"},{"content":"","date":"5 June 2026","externalUrl":null,"permalink":"/tags/log-analysis/","section":"Tags","summary":"","title":"Log Analysis","type":"tags"},{"content":"","date":"5 June 2026","externalUrl":null,"permalink":"/tags/low-fidelity-prototype/","section":"Tags","summary":"","title":"Low-Fidelity Prototype","type":"tags"},{"content":"","date":"5 June 2026","externalUrl":null,"permalink":"/tags/malware-investigation/","section":"Tags","summary":"","title":"Malware Investigation","type":"tags"},{"content":"","date":"5 June 2026","externalUrl":null,"permalink":"/tags/memory-analysis/","section":"Tags","summary":"","title":"Memory Analysis","type":"tags"},{"content":"","date":"5 June 2026","externalUrl":null,"permalink":"/tags/mutual-tls/","section":"Tags","summary":"","title":"Mutual TLS","type":"tags"},{"content":"","date":"5 June 2026","externalUrl":null,"permalink":"/tags/mvc/","section":"Tags","summary":"","title":"MVC","type":"tags"},{"content":"","date":"5 June 2026","externalUrl":null,"permalink":"/tags/network-forensics/","section":"Tags","summary":"","title":"Network Forensics","type":"tags"},{"content":"","date":"5 June 2026","externalUrl":null,"permalink":"/tags/networking/","section":"Tags","summary":"","title":"Networking","type":"tags"},{"content":"","date":"5 June 2026","externalUrl":null,"permalink":"/tags/nist-800-61/","section":"Tags","summary":"","title":"NIST 800-61","type":"tags"},{"content":"","date":"5 June 2026","externalUrl":null,"permalink":"/tags/object-oriented-programming/","section":"Tags","summary":"","title":"Object-Oriented Programming","type":"tags"},{"content":"","date":"5 June 2026","externalUrl":null,"permalink":"/tags/openstack/","section":"Tags","summary":"","title":"OpenStack","type":"tags"},{"content":"","date":"5 June 2026","externalUrl":null,"permalink":"/tags/openvpn/","section":"Tags","summary":"","title":"OpenVPN","type":"tags"},{"content":"","date":"5 June 2026","externalUrl":null,"permalink":"/tags/owasp-zap/","section":"Tags","summary":"","title":"OWASP ZAP","type":"tags"},{"content":"","date":"5 June 2026","externalUrl":null,"permalink":"/tags/patriot-act/","section":"Tags","summary":"","title":"Patriot Act","type":"tags"},{"content":"","date":"5 June 2026","externalUrl":null,"permalink":"/tags/penn-state/","section":"Tags","summary":"","title":"Penn State","type":"tags"},{"content":"","date":"5 June 2026","externalUrl":null,"permalink":"/tags/persistence/","section":"Tags","summary":"","title":"Persistence","type":"tags"},{"content":"","date":"5 June 2026","externalUrl":null,"permalink":"/tags/pfsense/","section":"Tags","summary":"","title":"PfSense","type":"tags"},{"content":"","date":"5 June 2026","externalUrl":null,"permalink":"/tags/phishing/","section":"Tags","summary":"","title":"Phishing","type":"tags"},{"content":"","date":"5 June 2026","externalUrl":null,"permalink":"/tags/polymorphism/","section":"Tags","summary":"","title":"Polymorphism","type":"tags"},{"content":"","date":"5 June 2026","externalUrl":null,"permalink":"/tags/privacy/","section":"Tags","summary":"","title":"Privacy","type":"tags"},{"content":"","date":"5 June 2026","externalUrl":null,"permalink":"/tags/productivity-assistant/","section":"Tags","summary":"","title":"Productivity Assistant","type":"tags"},{"content":"","date":"5 June 2026","externalUrl":null,"permalink":"/tags/professional-experience/","section":"Tags","summary":"","title":"Professional Experience","type":"tags"},{"content":"","date":"5 June 2026","externalUrl":null,"permalink":"/tags/programming-fundamentals/","section":"Tags","summary":"","title":"Programming Fundamentals","type":"tags"},{"content":"","date":"5 June 2026","externalUrl":null,"permalink":"/categories/projects/","section":"Categories","summary":"","title":"Projects","type":"categories"},{"content":"Portfolio Gallery\nThis page is organized by review value, not just by course number.\nThe first section is what I would point to first for ServiceNow SecOps, cybersecurity analyst, incident response, forensics, or GRC conversations. The later sections fill in the technical foundation behind that work: networking, risk analysis, HCI, cloud, software development, and web design.\nPublishing note: These are public summaries. I do not publish raw lab files, malware samples, forensic images, full academic answers, credentials, private screenshots, client information, or sensitive implementation details.\nStart Here: Strongest Evidence # ServiceNow SecOps Lab Hub # This is the most directly career-aligned section of the portfolio. It covers Vulnerability Response workflow thinking: vulnerable item triage, assignment ownership, remediation tracking, validation, exceptions, and closure.\nPrimary Focus ServiceNow SecOps CYBER 440: Cybersecurity Capstone Incident Response \u0026amp; Forensics # A capstone investigation where I had to connect multiple evidence sources into one incident story: phishing, malware activity, forensic images, memory artifacts, logs, affected systems, impact, and remediation.\nCapstone Incident Response CYBER 366: Malware Analytics \u0026amp; Reverse Engineering Lab Collection # Hands-on malware analysis work covering static analysis, dynamic analysis, UPX unpacking, strings/FLOSS, ProcMon, RegShot, IDA Pro, Ghidra, Binary Ninja, anti-debugging, and keylogging indicators.\nMalware Analysis Reverse Engineering IST 454: Computer \u0026amp; Cyber Forensics Lab Evidence # Selected forensic evidence from the course: forensic imaging, mounting, hash verification, registry analysis, data carving, deleted file recovery, and AI/IoT forensics research.\nDigital Forensics Evidence Handling IST 456: Security \u0026amp; Risk Management with Enigma Glass Labs # Security management work that bridges SOC-style investigation and GRC: ransomware, compromised credentials, data exfiltration, ISO 27000 concepts, policy, contingency planning, and risk-based recommendations.\nRisk Management GRC + SOC IST 495: Penn State College of IST Network Lab Development Internship # Professional internship experience with Penn State College of IST. I worked on networking lab modernization, technical research, lab validation, documentation, rubrics, teamwork, and supervisor updates.\nInternship Networking Incident Response, Forensics, Malware, and Security Operations # Project Why it matters Area CYBER 342W: Incident Response, Disaster Recovery \u0026 Business Continuity Planning This is the planning side of incident response: NIST 800-61, CSIRT structure, communication, containment, recovery, DR/BC, and post-incident lessons learned. IR Planning IST 451: Malware-Based Attack Investigation Lab A defensive investigation lab focused on suspicious traffic, firewall logs, containment, spoofing indicators, packet capture review, and process identification. Investigation IST 451: Security Labs Collection A broader security lab collection covering service identification, Apache hardening, OpenVAS, SQL injection concepts, malware analysis, IDS concepts, and wireless security. Security Labs CYBER 262: Security Foundations Lab Collection A hands-on foundation course: Linux logs, Python parsing, host-based defense, Wazuh, Snort, Splunk, 2FA, and buffer overflow concepts. Foundations SRA 221: Information Security Foundations Lab Collection Earlier security-tool exposure: OWASP ZAP, reconnaissance, Wireshark, SPARTA, OpenVPN, pfSense, Active Directory, file system forensics, and Splunk. Intro Security CYBER 362: Network Traffic Analysis \u0026 ML-Based Anomaly Detection Packet investigation, suspicious file analysis, Splunk review, clustering, supervised machine learning, and anomaly detection concepts. Traffic + ML GRC, Risk, Privacy, and Decision Analysis # Project Why it matters Area IST 432: Cyber Law, Privacy \u0026 GRC Case Analysis Cyber law and governance work: privacy, surveillance authority, Fourth Amendment concerns, CFAA authorization boundaries, cybersquatting, platform governance, and cybercrime scenarios. Cyber Law SRA 311: Risk Analysis in a Security Context Applied risk analysis: analytic confidence, source credibility, risk matrices, weighted ranking, organizational risk maturity, cyber hygiene, threat modeling, and risk treatment. Risk Analysis SRA 231: Decision Theory \u0026 Analysis for Security Reasoning The decision-theory foundation behind risk work: decision matrices, decision trees, decisions under ignorance, decisions under risk, expected value, and group decisions. Decision Theory OT/ICS, Cloud, HCI, and Software Foundations # Project Why it matters Area IST 451: ICS/IT-OT Application-Level DoS Attack Lab OT/ICS security work focused on SCADA visibility disruption, application-level DoS behavior, operational impact, and recovery validation. OT/ICS IST 402: Cloud Virtualization, Containers \u0026 SECaaS Architecture Cloud and emerging technology work: Hyper-V, OpenStack, Docker, Docker Compose, secure cloud architecture, mTLS, zero trust, workflow modeling, and SECaaS strategy. Cloud Security IST 331: User-Centered Design \u0026 Booking.com Redesign The HCI evidence behind how I think about usability: user research, low/high-fidelity prototypes, Figma collaboration, usability testing, and iterative redesign. HCI IST 261: Productivity Assistant Application Design Studio Application design work with requirements thinking, noun/verb analysis, OOP modeling, MVC, persistence, task queues, GUI workflows, and testing. App Design IST 242: Intermediate Java \u0026 Object-Oriented Application Development Intermediate Java work with inheritance, abstract classes, interfaces, polymorphism, Swing GUI development, validation, and cleaner application structure. Intermediate Java IST 240: Introductory Java Programming \u0026 OOP Lab Progression The early Java foundation: classes, constructors, methods, encapsulation, inheritance, arrays, ArrayLists, search logic, and model/data separation. Java Basics IST 311: Java Data Structures, OOP \u0026 Software Engineering Foundations The stronger software engineering layer: data structures, Big-O, object-oriented design, UML/CRC, testing, debugging, and Git workflow practice. Data Structures IST 250: Uphill Struggle Bicycles Web Design Project Early web design work with page structure, navigation, front-end presentation, usability thinking, and building a complete website concept. Web Design Concepts and Site-Building Work # AI-Powered Vulnerability Ownership Recommender # A concept for AI-assisted ServiceNow SecOps decision support: vulnerable item ownership, assignment group routing, remediation path suggestions, escalation priority, and analyst-reviewed recommendations.\nAI SecOps Concept sudoRunner Portfolio Website # This website is also a project: Hugo, Blowfish, GitHub, Cloudflare Pages, DNS, email routing, custom styling, mobile HCI fixes, favicon branding, guided review paths, and security-conscious publishing.\nHugo + Cloudflare HCI Quick Review Guidance # Best for ServiceNow / Vulnerability Response # Start with the ServiceNow SecOps Lab Hub, then review IST 456 and the AI ownership recommender concept.\nSecOps Path\nBest for Cybersecurity Analyst Roles # Start with CYBER 440, CYBER 366, IST 454, CYBER 362, CYBER 262, and IST 456.\nAnalyst Path\nBest for GRC / Risk Conversations # Start with IST 456, IST 432, SRA 311, SRA 231, and CYBER 342W.\nRisk Path\nServiceNow SecOps CYBER 440 Capstone CYBER 366 Malware Capabilities ","date":"5 June 2026","externalUrl":null,"permalink":"/projects/","section":"Projects","summary":"","title":"Projects","type":"projects"},{"content":"","date":"5 June 2026","externalUrl":null,"permalink":"/tags/quality-assurance/","section":"Tags","summary":"","title":"Quality Assurance","type":"tags"},{"content":"","date":"5 June 2026","externalUrl":null,"permalink":"/tags/queues/","section":"Tags","summary":"","title":"Queues","type":"tags"},{"content":"","date":"5 June 2026","externalUrl":null,"permalink":"/tags/ransomware/","section":"Tags","summary":"","title":"Ransomware","type":"tags"},{"content":"","date":"5 June 2026","externalUrl":null,"permalink":"/tags/reconnaissance/","section":"Tags","summary":"","title":"Reconnaissance","type":"tags"},{"content":"","date":"5 June 2026","externalUrl":null,"permalink":"/tags/registry-analysis/","section":"Tags","summary":"","title":"Registry Analysis","type":"tags"},{"content":"","date":"5 June 2026","externalUrl":null,"permalink":"/tags/regripper/","section":"Tags","summary":"","title":"RegRipper","type":"tags"},{"content":"","date":"5 June 2026","externalUrl":null,"permalink":"/tags/risk-analysis/","section":"Tags","summary":"","title":"Risk Analysis","type":"tags"},{"content":"","date":"5 June 2026","externalUrl":null,"permalink":"/tags/risk-management/","section":"Tags","summary":"","title":"Risk Management","type":"tags"},{"content":"","date":"5 June 2026","externalUrl":null,"permalink":"/tags/risk-matrix/","section":"Tags","summary":"","title":"Risk Matrix","type":"tags"},{"content":"","date":"5 June 2026","externalUrl":null,"permalink":"/tags/risk-treatment/","section":"Tags","summary":"","title":"Risk Treatment","type":"tags"},{"content":"","date":"5 June 2026","externalUrl":null,"permalink":"/tags/secaas/","section":"Tags","summary":"","title":"SECaaS","type":"tags"},{"content":"","date":"5 June 2026","externalUrl":null,"permalink":"/tags/security-foundations/","section":"Tags","summary":"","title":"Security Foundations","type":"tags"},{"content":"","date":"5 June 2026","externalUrl":null,"permalink":"/tags/security-reasoning/","section":"Tags","summary":"","title":"Security Reasoning","type":"tags"},{"content":"","date":"5 June 2026","externalUrl":null,"permalink":"/tags/security-risk/","section":"Tags","summary":"","title":"Security Risk","type":"tags"},{"content":"","date":"5 June 2026","externalUrl":null,"permalink":"/tags/security-risk-management/","section":"Tags","summary":"","title":"Security Risk Management","type":"tags"},{"content":"","date":"5 June 2026","externalUrl":null,"permalink":"/tags/security-strategy/","section":"Tags","summary":"","title":"Security Strategy","type":"tags"},{"content":"","date":"5 June 2026","externalUrl":null,"permalink":"/tags/siem/","section":"Tags","summary":"","title":"SIEM","type":"tags"},{"content":"","date":"5 June 2026","externalUrl":null,"permalink":"/tags/software-design/","section":"Tags","summary":"","title":"Software Design","type":"tags"},{"content":"","date":"5 June 2026","externalUrl":null,"permalink":"/tags/software-foundations/","section":"Tags","summary":"","title":"Software Foundations","type":"tags"},{"content":"","date":"5 June 2026","externalUrl":null,"permalink":"/tags/source-credibility/","section":"Tags","summary":"","title":"Source Credibility","type":"tags"},{"content":"","date":"5 June 2026","externalUrl":null,"permalink":"/tags/sparta/","section":"Tags","summary":"","title":"SPARTA","type":"tags"},{"content":"","date":"5 June 2026","externalUrl":null,"permalink":"/tags/splunk/","section":"Tags","summary":"","title":"Splunk","type":"tags"},{"content":" Information Security Foundations Case Study\nThis portfolio-safe case study summarizes selected SRA 221 Overview of Information Security lab work focused on foundational security operations, web application security analysis, reconnaissance, protocol analysis, service discovery, automated security analysis, VPN configuration, firewall configuration, Active Directory user management, file system forensics, and Splunk log analytics.\nCourse SRA 221 Project Type Information Security Foundations Lab Collection Focus Security Tools · Networking · Access · Logs · Forensics Tools / Platforms OWASP ZAP · Wireshark · SPARTA · OpenVPN · pfSense · Active Directory · Splunk Professional Angle Foundational Security Operations and Analyst Readiness Publishing Level Portfolio-Safe / No Raw Lab Screenshots Published Overview # SRA 221 provided an early overview of information security through a sequence of hands-on labs.\nThe available coursework supports a broad foundational security narrative covering:\nlab environment setup web application security testing with OWASP ZAP website reconnaissance protocol analysis with Wireshark live machine and service discovery automated security analysis with SPARTA VPN server configuration with OpenVPN firewall configuration with pfSense Active Directory domain user account management introductory file system forensics log analytics with Splunk cyber incident writing and breach analysis This page is intentionally written as a portfolio-safe summary. It does not publish raw screenshots, full lab submissions, private lab credentials, complete answers, or detailed step-by-step procedures.\nThe strongest portfolio angle is security foundations. This course helped establish practical awareness of the tools and concepts that later appear in more advanced cybersecurity work, including CYBER 262, CYBER 366, CYBER 440, IST 454, IST 456, and ServiceNow SecOps workflow thinking.\nWhy This Project Matters # SRA 221 matters because it represents the early hands-on layer of my cybersecurity education.\nBefore advanced malware analysis, incident response, forensics, or ServiceNow SecOps work, a security analyst needs a base understanding of:\nhow web application testing tools identify issues how reconnaissance supports assessment how packets reveal communication behavior how to identify live systems and services how automated scanning can support analysis how VPNs support secure remote access how firewalls enforce traffic control how directory services manage users how file systems can contain forensic evidence how SIEM/log analytics tools support detection This course helped build that practical foundation.\nPortfolio-Safe Publishing Approach # Security and academic integrity note: This case study summarizes foundational information security lab work without publishing raw screenshots, credentials, private lab details, full submissions, complete answers, or copy-paste-ready procedures.\nThis page excludes:\nraw lab screenshots complete academic submissions private lab credentials private course instructions raw scan results exact lab environment details full answer sheets copy-paste-ready procedures private student identifiers Instead, it presents:\nlab topics security concepts tools used portfolio-safe summaries professional lessons learned connection to later cybersecurity work Lab Collection Summary # Lab Portfolio-Safe Summary Focus Lab 01: Cyrin Labs and Account Setup Set up and accessed the lab environment used for later hands-on security exercises. Lab Setup Lab 02: Web Application Security Analysis Using OWASP ZAP Introduced web application security testing concepts using OWASP ZAP to analyze web application behavior and identify potential issues. Web App Security Lab 03: Web Site Reconnaissance Practiced reconnaissance concepts used to collect information about a website or target environment before deeper analysis. Reconnaissance Lab 04: Protocol Analysis I — Wireshark Basics Used Wireshark concepts to review network protocol behavior and understand packet-level communication. Protocol Analysis Lab 05: Identifying Live Machines and Services on an Unknown Network Practiced host and service discovery concepts to identify live machines and exposed services in a networked environment. Service Discovery Lab 06: Automating Security Analysis with SPARTA Introduced automated security analysis concepts using SPARTA-style reconnaissance and enumeration workflows. Automated Analysis Lab 07: VPN Server Configuration with OpenVPN Worked with VPN server configuration concepts related to secure remote access and encrypted connectivity. VPN Lab 08: Firewall Configuration with pfSense Practiced firewall configuration concepts using pfSense, including traffic control and perimeter security thinking. Firewall Lab 09: Active Directory Domain User Accounts Worked with Active Directory concepts related to domain user account management and centralized identity administration. Identity Lab 10: Introductory File System Forensics Introduced file system forensics concepts, supporting later work in digital forensics and incident investigation. Forensics Lab 11: Log Analytics with Splunk Introduced log analytics concepts using Splunk, supporting later SIEM, detection, investigation, and security operations work. Splunk Major Security Domains Covered # Web Application Security # OWASP ZAP and web security analysis introduced how web applications can be tested for potential security issues.\nOWASP ZAP\nReconnaissance and Enumeration # Website reconnaissance, live machine identification, and service discovery introduced early assessment methodology.\nRecon\nNetwork Protocol Analysis # Wireshark helped connect security analysis to packet-level communication and protocol behavior.\nWireshark\nSecure Remote Access # OpenVPN lab work introduced VPN server configuration and encrypted remote access concepts.\nOpenVPN\nFirewall Configuration # pfSense firewall configuration introduced traffic control, access restriction, and defensive network boundary concepts.\npfSense\nIdentity and Access # Active Directory lab work introduced centralized identity and domain user account management.\nActive Directory\nFile System Forensics # Introductory forensics work connected file system evidence to investigation and incident response concepts.\nForensics\nLog Analytics # Splunk introduced SIEM-style thinking around log search, event review, and security investigation.\nSplunk\nTechnical Learning Path # 1 Establish the Lab Environment # Started with account setup and lab access so later security exercises could be performed in a controlled environment.\nLab Setup\n2 Analyze Web and Network Surfaces # Moved into web application security, website reconnaissance, and protocol analysis.\nWeb / Network\n3 Discover Hosts and Services # Practiced identifying live machines, exposed services, and network visibility.\nDiscovery\n4 Automate Reconnaissance and Assessment # Used SPARTA-style automated analysis concepts to support enumeration and security review.\nAutomation\n5 Configure Defensive Infrastructure # Worked with OpenVPN and pfSense concepts to understand remote access and firewall control.\nDefense\n6 Connect Identity, Forensics, and Logs # Finished with Active Directory, file system forensics, and Splunk log analytics, linking identity and evidence to investigation workflows.\nInvestigation\nWeb Application Security Evidence # The OWASP ZAP lab introduced web application security analysis.\nPortfolio-safe concepts included:\nweb application testing workflow proxy-based security analysis identifying potential application issues understanding how automated tools support review recognizing that tool results still require analyst interpretation connecting web testing to broader application security awareness This supports later vulnerability management and ServiceNow SecOps work because web application findings need triage, ownership, remediation, validation, and documentation.\nReconnaissance and Service Discovery Evidence # The reconnaissance and unknown-network labs introduced early assessment concepts.\nPortfolio-safe concepts included:\ninformation gathering identifying visible services understanding target exposure recognizing live systems documenting findings using reconnaissance as an early phase of security assessment This is relevant to vulnerability management because you cannot secure what you cannot identify.\nProtocol Analysis Evidence # The Wireshark lab introduced packet-level analysis.\nPortfolio-safe concepts included:\nreviewing network traffic understanding protocols observing communication behavior interpreting packet-level data using network evidence to support technical analysis This supports later work in CYBER 362 network traffic analysis, CYBER 440 incident response, and general security operations.\nVPN and Firewall Evidence # The OpenVPN and pfSense labs introduced defensive infrastructure concepts.\nPortfolio-safe concepts included:\nsecure remote access encrypted VPN connectivity firewall configuration traffic filtering access control network boundary protection defensive network architecture These concepts matter because security operations depends on understanding the controls that protect network access and traffic flow.\nActive Directory Evidence # The Active Directory lab introduced centralized identity concepts.\nPortfolio-safe concepts included:\ndomain user account management identity administration centralized account control access management foundations relationship between identity and security operations This is relevant because identity is central to modern cybersecurity. Many incidents involve account compromise, privilege misuse, weak credentials, or poor access governance.\nFile System Forensics Evidence # The introductory forensics lab connected information security to evidence handling.\nPortfolio-safe concepts included:\nfile system evidence forensic thinking investigation workflow artifact review relationship between file evidence and incident investigation This supports later forensic work in IST 454 and CYBER 440.\nSplunk Log Analytics Evidence # The Splunk lab introduced log analytics and SIEM-style analysis.\nPortfolio-safe concepts included:\nsearching log data reviewing events interpreting security-relevant records using logs to support investigation connecting system activity to analyst conclusions This supports later work in SIEM, detection, incident response, ServiceNow SecOps, and cybersecurity analysis.\nBreach Writing and Security Awareness # The extra writing assignment reviewed a recurring payment-system breach involving compromised payment records across multiple cities.\nThe useful portfolio angle is not the specific breach itself, but the reasoning it supported:\nrecurring incidents suggest failed remediation patching and recovery processes must be validated repeated compromise can create accountability concerns smaller breaches still matter when prior incidents were not fully resolved security writing must explain impact clearly The “Do Something Good” assignment is not a cybersecurity lab, so it is not central to this page. It can be treated as a minor civic/community note, but not a main portfolio artifact.\nCapability-to-Evidence Map # Capability Evidence from SRA 221 Status Web Application Security Awareness Worked with OWASP ZAP concepts for web application security analysis and vulnerability-oriented review. Completed Reconnaissance and Enumeration Practiced website reconnaissance, identifying live machines, and identifying services on an unknown network. Completed Protocol Analysis Used Wireshark basics to review protocol behavior and network communication. Completed Defensive Infrastructure Worked with OpenVPN and pfSense concepts for VPN access, firewall configuration, and traffic control. Completed Identity Foundations Worked with Active Directory concepts for centralized domain user account management. Completed Forensics Foundations Completed introductory file system forensics work supporting later digital forensics and incident investigation coursework. Completed Log Analytics Worked with Splunk log analytics concepts supporting SIEM, detection, and security investigation foundations. Completed Relationship to Later Coursework # SRA 221 is best understood as an early foundation for later cybersecurity coursework.\nLater Course / Project How SRA 221 Supports It Connection CYBER 262 SRA 221 introduced core lab and security tool familiarity before deeper security foundations, Linux/Python, HIDS/NIDS, Splunk, and buffer overflow work. Security Foundations CYBER 362 Wireshark and protocol analysis foundations support later network traffic analysis and ML-based anomaly detection work. Traffic Analysis IST 454 Introductory file system forensics supports later forensic imaging, registry analysis, data carving, and evidence handling work. Forensics CYBER 440 Splunk, logs, network analysis, and forensics foundations support later capstone incident response and forensic investigation work. IR Capstone IST 456 SIEM-style thinking, identity, firewall, and risk concepts support later security risk management and Enigma Glass lab work. Risk Management ServiceNow SecOps Web findings, service discovery, identity issues, firewall controls, forensic evidence, and logs all map to triage and remediation workflows. SecOps Workflow What I Learned # This course reinforced several foundational lessons:\nsecurity tools require analyst interpretation reconnaissance is a normal part of security assessment network traffic can reveal important technical context exposed services expand attack surface automated scanning can assist but not replace analysis VPNs and firewalls support secure access and traffic control identity management is central to security operations file systems can contain investigative evidence logs are essential for detection and response early security foundations support more advanced malware, forensics, SIEM, and incident response work Professional Relevance # This project supports roles and tasks involving:\ncybersecurity analysis security operations vulnerability management ServiceNow SecOps consulting web application security awareness network investigation firewall and VPN awareness Active Directory basics digital forensics foundations Splunk/log analytics foundations incident response preparation It is especially relevant to ServiceNow SecOps because findings from web testing, reconnaissance, identity review, firewall controls, forensic evidence, and logs often need to become tracked work: triage, ownership, remediation, validation, exception handling, and closure.\nDifference from CYBER 262 # SRA 221 and CYBER 262 both support security foundations, but they play different roles.\nCourse Main Portfolio Angle Best Evidence Type SRA 221 Introductory information security tool exposure across web security, recon, Wireshark, OpenVPN, pfSense, Active Directory, forensics, and Splunk. Foundations CYBER 262 Deeper cybersecurity foundations involving Linux, Python parsing, endpoint security, Wazuh HIDS, Snort NIDS, Splunk, 2FA, and buffer overflow concepts. Hands-On Labs SRA 221 is best treated as the earlier overview course that prepared the ground for later technical cybersecurity lab work.\nPortfolio-Safe Redaction Notes # This case study intentionally excludes:\nraw lab screenshots full lab submissions private lab credentials complete answer sheets exact lab environment details private course instructions full scan outputs copy-paste-ready procedures The goal is to show information security foundation and tool exposure without publishing raw academic work.\nRelated Portfolio Areas # Security Operations # This work supports early SOC-style foundations through logs, protocol analysis, identity, firewall, and forensic awareness.\nSOC-Relevant\nVulnerability Management # OWASP ZAP, reconnaissance, and service discovery support understanding of exposure and remediation workflows.\nVulnerability-Relevant\nDigital Forensics # Introductory file system forensics supports later IST 454 and CYBER 440 evidence-handling work.\nForensics Foundation\nServiceNow SecOps # Foundational security findings become meaningful when they are tracked, assigned, remediated, validated, and closed.\nSecOps-Relevant\nNext Steps # This project can later be connected to:\nthe cybersecurity foundations capability section the CYBER 262 page the IST 454 forensics page the CYBER 440 capstone page a security operations review path a web application security foundations note a log analytics / Splunk foundations note For now, this page serves as the main portfolio-safe summary of my SRA 221 Overview of Information Security work.\n","date":"5 June 2026","externalUrl":null,"permalink":"/projects/sra-221-information-security-foundations-lab-collection/","section":"Projects","summary":"","title":"SRA 221: Information Security Foundations Lab Collection","type":"projects"},{"content":" Decision Theory / Risk Reasoning Case Study\nThis portfolio-safe case study summarizes selected SRA 231 Decision Theory and Analysis work focused on decision matrices, decision trees, decisions under ignorance, decisions under risk, expected value, expected utility, group decisions, perception bias, and structured reasoning in uncertain situations.\nCourse SRA 231 Project Type Decision Theory / Structured Analysis Case Study Focus Decision Matrix · Decision Tree · Risk · Ignorance · Expected Value Methods Dominance · Maximin · Maximax · Expected Value · Group Decisions Professional Angle Security Reasoning, Risk Prioritization, and Decision Support Publishing Level Portfolio-Safe / No Raw Academic Submissions Published Overview # SRA 231 introduced decision theory and structured analysis methods.\nThe course focused on how people make decisions under uncertainty, risk, and incomplete information. The work included decision matrices, decision trees, decisions under ignorance, expected value, expected utility, group decisions, behavioral decision-making, perception bias, and game-theory-style reasoning.\nThis course is valuable in my cybersecurity portfolio because security work often involves uncertain decisions:\nwhich risk should be prioritized first whether to contain or observe suspicious activity whether to accept, transfer, mitigate, or avoid risk whether evidence is strong enough to escalate how to compare multiple imperfect alternatives how to account for human bias and perception how group decision-making affects outcomes how to explain a decision path clearly SRA 231 provides the foundational decision-analysis layer behind later work in SRA 311, GRC, vulnerability management, incident response, and ServiceNow SecOps workflow design.\nWhy This Project Matters # Cybersecurity decisions are rarely made with perfect information.\nAnalysts and consultants frequently need to choose between alternatives while dealing with:\nincomplete evidence uncertain likelihood unclear consequences competing priorities business constraints user behavior team decision-making risk tolerance time pressure Decision theory helps create a structured way to reason through those situations.\nThis course helped build the habit of breaking decisions into:\nissue alternatives states of the world outcomes preferences probabilities uncertainty risk attitude group behavior recommended action That structure is directly relevant to cybersecurity risk analysis and professional decision support.\nPortfolio-Safe Publishing Approach # Security and academic integrity note: This case study summarizes decision theory coursework without publishing raw academic submissions, complete answers, private course instructions, or full decision diagrams.\nThis page excludes:\nraw academic submissions complete decision tree images full assignment answers private student identifiers private course materials complete discussion posts copy-paste-ready academic work Instead, it presents:\ndecision concepts practiced analysis methods used portfolio-safe summaries cybersecurity relevance professional lessons learned connection to risk and GRC work Major Workstreams # Decision Matrix # Used alternatives, states of the world, and outcome descriptions to compare choices in uncertain everyday scenarios.\nDecision Structure\nDecision Tree # Modeled branching choices and possible states to visualize how decisions lead to different outcomes.\nDecision Tree\nDecisions Under Ignorance # Practiced decision-making when probabilities are unknown, using principles such as dominance, maximin, maximax, and related decision criteria.\nUncertainty\nDecisions Under Risk # Reviewed decisions where outcome probabilities are known or estimated, including expected monetary value, expected value, and expected utility.\nRisk\nGroup Decisions # Explored how group decision-making can differ from individual decision-making and how social context affects rational outcomes.\nGroup Decisions\nBehavioral Decision-Making # Reflected on perception, bias, intuition, random decision methods, and prisoner’s dilemma behavior.\nBehavioral Analysis\nDecision Methods Practiced # Method / Concept Portfolio-Safe Summary Decision Angle Decision Matrix Compared alternatives and states of the world by describing possible outcomes and choosing the alternative with the most acceptable result. Alternatives Decision Tree Mapped a decision into a branching structure where choices and uncertain outcomes could be visualized. Branching Logic Dominance Principle Evaluated whether one alternative was at least as good as another across all states and better in at least one state. Rational Choice Maximin Focused on the worst possible outcome for each alternative and selected the option with the best worst-case result. Conservative Choice Maximax Focused on the best possible outcome for each alternative and selected the option with the highest upside. Optimistic Choice Expected Value Reviewed decisions where probabilities are known or estimated and outcomes can be weighted by likelihood. Probability Expected Utility Considered how preferences and satisfaction can matter even when monetary value or simple numeric outcomes do not tell the whole story. Preference Prisoner’s Dilemma Explored how individual incentives and group outcomes can diverge, and how cooperation or betrayal changes outcomes. Game Theory Decision Analysis Workflow # 1 Define the Issue # The first step was to state the decision problem clearly, such as whether to take a protective action or choose between uncertain alternatives.\nIssue Definition\n2 Identify Alternatives # Each decision was broken into possible actions or alternatives that the decision-maker could choose.\nAlternatives\n3 Identify States of the World # The analysis considered possible future states that could affect whether the decision was good or bad.\nUncertainty\n4 Compare Outcomes # Outcomes were described or scored based on how desirable, undesirable, risky, costly, or beneficial they were.\nOutcome Review\n5 Apply a Decision Rule # Different decision principles were applied depending on whether the problem involved ignorance, risk, utility, or group behavior.\nDecision Rule\n6 Explain the Recommendation # The final step was explaining why one alternative was preferred based on the chosen method and assumptions.\nRecommendation\nDecision Matrix and Decision Tree Evidence # One early assignment used a simple everyday decision problem to practice a decision matrix and decision tree.\nThe value of the assignment was not the specific scenario. The value was learning how to structure a decision by separating:\nthe issue possible alternatives possible future states outcome descriptions preferred choice reasoning behind the recommendation This same structure applies to cybersecurity decisions.\nFor example, a security team might ask:\nShould we disable a suspicious account now or monitor it further? Should we immediately isolate a host or collect more evidence first? Should we patch a vulnerable system now or wait for a maintenance window? Should we accept a low-likelihood risk or invest in mitigation? Should we require MFA for a user population even if it introduces friction? Decision matrices and decision trees help make these tradeoffs explicit.\nDecisions Under Ignorance # The decisions-under-ignorance assignment focused on decisions where probabilities were not known.\nThis is relevant because cybersecurity teams often face uncertainty:\nthe true likelihood of exploitation may be unknown the attacker’s intent may be unclear the full business impact may not be known yet the reliability of evidence may vary the environment may not have complete telemetry Decision principles such as dominance, maximin, and maximax help frame different risk attitudes.\nA conservative security team may prefer a maximin-style approach when the worst-case outcome is severe. A more risk-tolerant decision-maker may focus on potential upside, cost savings, or operational continuity.\nThe key lesson is that the decision rule chosen can change the recommendation.\nDecisions Under Risk # The risk-focused work reviewed decisions where probabilities are known or can be estimated.\nThe course covered:\ndecisions under risk complete or partial knowledge of probabilities expected monetary value expected value expected utility use of probabilities in rational choice group decision contexts This matters in cybersecurity because risk-based prioritization often depends on probability and impact.\nExamples include:\nexpected loss from downtime likelihood of ransomware spread expected value of a mitigation control cost-benefit comparison of security tools vulnerability prioritization based on exploitation likelihood risk acceptance decisions compensating control decisions The course helped build the habit of connecting uncertainty to structured decision logic.\nGroup Decisions and Prisoner’s Dilemma # The course also explored group decision-making and prisoner’s dilemma behavior.\nThe key theme was that individual rational decisions do not always produce the best group outcome.\nThis matters in security because people and teams often make decisions that are locally rational but globally risky.\nExamples include:\na user bypassing security controls to save time a team delaying patching to avoid operational disruption departments avoiding disclosure to reduce blame organizations underinvesting in shared controls users choosing convenience over password hygiene teams failing to cooperate during an incident The prisoner’s dilemma lens helps explain why incentives, communication, coordination, and trust matter in security programs.\nPerception and Bias # One discussion assignment focused on color perception and how prior knowledge can influence interpretation.\nThe cybersecurity relevance is that analysts can also be influenced by perception and bias.\nExamples include:\nassuming an alert is false positive because similar alerts were noisy before giving more weight to familiar tools overlooking evidence that contradicts an early theory interpreting ambiguous logs according to a preferred explanation allowing prior experience to shape current conclusions The lesson is that decision-making is not purely mechanical. Human perception, intuition, memory, and bias can affect how evidence is interpreted.\nRandomness vs Structured Choice # Another discussion reflected on a fictional random decision-making method using dice.\nThe lesson was that random choice may resolve indecision, but it does not replace structured reasoning.\nIn security, random or arbitrary decisions are dangerous when consequences are high.\nSecurity decisions should be based on:\nevidence impact likelihood business priority risk tolerance available controls stakeholder needs known constraints decision rationale This maps well to professional security work because decisions need to be explainable and defensible.\nCapability-to-Evidence Map # Capability Evidence from SRA 231 Status Structured Decision-Making Used decision matrices and decision trees to break choices into alternatives, states, outcomes, and recommendations. Completed Decision-Making Under Ignorance Applied dominance, maximin, maximax, and related principles when probabilities were unknown. Completed Decision-Making Under Risk Reviewed expected monetary value, expected value, expected utility, and probability-informed decision-making. Completed Behavioral Decision Analysis Reflected on perception, bias, intuition, random decision methods, and prisoner’s dilemma behavior. Completed Group Decision Awareness Explored how individual and group outcomes can diverge and how cooperation, incentives, and context affect decisions. Completed Security-Relevant Reasoning Built decision-analysis foundations that support later risk analysis, GRC, incident response, and vulnerability prioritization work. Completed Relationship to SRA 311 # SRA 231 and SRA 311 should be read as a progression.\nCourse Main Portfolio Angle Best Evidence Type SRA 231 Foundational decision theory, decision matrices, decision trees, decisions under risk/ignorance, expected value, group decisions, and behavioral decision-making. Decision Theory SRA 311 Applied security risk analysis, source credibility, analytic confidence, weighted ranking, organizational risk maturity, threat modeling, and risk treatment. Security Risk Analysis SRA 231 provides the decision-analysis foundation. SRA 311 applies that foundation more directly to security risk analysis.\nCybersecurity and GRC Relevance # This course supports cybersecurity and GRC work because decision-making is central to risk management.\nRelevant security applications include:\nvulnerability prioritization risk acceptance control selection incident escalation evidence evaluation patch timing containment decisions business impact review exception handling stakeholder communication decision documentation Decision theory supports these tasks by making the reasoning more explicit.\nWhat I Learned # This course reinforced several lessons:\ndecisions should be structured before they are judged alternatives and states of the world should be separated clearly different decision rules can produce different recommendations worst-case thinking and best-case thinking reflect different risk attitudes probabilities matter when they are known or can be estimated utility and preference can differ from monetary value group decisions can produce outcomes that differ from individual incentives perception and prior beliefs can influence interpretation random choice is not the same as rational decision-making recommendations are stronger when assumptions are stated clearly Professional Relevance # This project supports roles and tasks involving:\ncybersecurity analysis GRC risk analysis vulnerability management incident response decision-making ServiceNow SecOps consulting stakeholder communication business impact analysis exception handling risk acceptance structured reasoning and decision documentation It is especially relevant to ServiceNow SecOps and Vulnerability Response because these workflows require prioritization, ownership, escalation, exception decisions, and clear justification.\nPortfolio-Safe Redaction Notes # This case study intentionally excludes:\nraw academic submissions full decision tree diagrams complete discussion posts private course materials private student identifiers complete assignment answers copy-paste-ready academic work The goal is to show decision theory and structured analysis foundations without publishing raw academic work.\nRelated Portfolio Areas # Risk Analysis # Decision theory supports later risk analysis work by creating structure around alternatives, uncertainty, outcomes, and recommendations.\nRisk Reasoning\nGRC # Governance and risk decisions require defensible reasoning, documented assumptions, and clear prioritization.\nGRC-Relevant\nServiceNow SecOps # SecOps workflows depend on prioritization, escalation, assignment, remediation, validation, exception handling, and risk communication.\nSecOps-Relevant\nSecurity Operations # Analysts need to explain why an alert, vulnerability, or incident deserves action under uncertainty.\nSOC-Relevant\nNext Steps # This project can later be connected to:\na risk and decision-analysis capability section the SRA 311 risk analysis page a ServiceNow risk-prioritization concept note a vulnerability exception decision model a decision matrix template for security triage an incident escalation decision tree a risk acceptance workflow concept For now, this page serves as the main portfolio-safe summary of my SRA 231 Decision Theory and Analysis work.\n","date":"5 June 2026","externalUrl":null,"permalink":"/projects/sra-231-decision-theory-analysis-security-reasoning/","section":"Projects","summary":"","title":"SRA 231: Decision Theory \u0026 Analysis for Security Reasoning","type":"projects"},{"content":" Risk Analysis / GRC Case Study\nThis portfolio-safe case study summarizes selected SRA 311 Risk Analysis in a Security Context work focused on analytic confidence, source credibility, tangible and testimonial evidence, risk matrices, weighted ranking, organizational risk maturity, threat-risk modeling, cyber hygiene, and security risk treatment.\nCourse SRA 311 Project Type Risk Analysis / Security Context Case Study Focus Risk Analysis · Decision Analysis · GRC · Threat Modeling Methods Analytic Confidence · Risk Matrix · Weighted Ranking · Source Credibility Team Project Cyber Risk Assessment for a Poor Cyber Hygiene Scenario Publishing Level Portfolio-Safe / No Raw Submissions Published Overview # SRA 311 focused on risk analysis in a security context. The course emphasized how analysts evaluate uncertainty, weigh evidence, assess credibility, compare risk methods, and translate threat scenarios into practical risk treatment plans.\nThis course is important to my portfolio because it strengthens the GRC and risk-analysis side of cybersecurity. It is not a technical tool lab. Instead, it demonstrates structured reasoning, uncertainty management, source credibility review, decision support, and risk communication.\nThe available coursework supports several major themes:\nanalytic confidence source reliability evidence credibility tangible versus testimonial evidence risk matrix use and limitations weighted ranking organizational risk maturity quantitative threat-risk modeling risk assessment methodology cyber hygiene risk phishing, malware, ransomware, and social engineering threat modeling risk treatment planning residual risk monitoring plans training and awareness security audit programs This page is intentionally written as a portfolio-safe summary. It does not publish raw assignments, full group submissions, private student identifiers, complete academic answers, or complete source materials.\nWhy This Project Matters # Cybersecurity is full of uncertainty.\nAnalysts and consultants often need to make recommendations when the available information is incomplete, ambiguous, or probabilistic. That requires more than technical knowledge. It requires a disciplined way to think about risk.\nSRA 311 helped develop that discipline by asking questions such as:\nHow confident should an analyst be in an assessment? What makes a source reliable? How should tangible evidence be evaluated? How should testimonial evidence be evaluated? When do risk matrices help? When can risk matrices mislead? How should alternatives be ranked? How do organizations mature in risk management? How should a cyber threat scenario be scoped? What controls reduce the likelihood or impact of a threat? What residual risk remains after treatment? How should risk be communicated to decision makers? These questions are directly relevant to cybersecurity consulting, security operations, ServiceNow SecOps, vulnerability management, GRC, incident response, and risk-based prioritization.\nPortfolio-Safe Publishing Approach # Security and academic integrity note: This case study summarizes risk analysis coursework without publishing raw assignments, full group reports, private student identifiers, full academic answers, or private source materials.\nThis page excludes:\nraw academic submissions full group reports private student identifiers complete assignment answers full source evaluation worksheets complete ranking tables private course material copy-paste-ready academic work Instead, it presents:\nrisk analysis concepts portfolio-safe summaries analysis workflow team project structure methods used professional lessons learned relevance to GRC and cybersecurity work Major Workstreams # Analytic Confidence # Explored how analysts express confidence in assessments based on evidence quality, source reliability, method use, collaboration, expertise, task complexity, and time pressure.\nUncertainty\nSource Credibility # Analyzed tangible and testimonial evidence, chain of custody, authenticity, source competence, credibility, and the weight of evidence in decision-making.\nEvidence Review\nRisk Matrix Critique # Studied risk matrices, their use in likelihood-impact ranking, and limitations such as false precision, weak resource allocation support, and misleading prioritization.\nRisk Methods\nWeighted Ranking # Practiced pairwise and weighted ranking methods to compare positive opportunities and negative outcomes based on overall value or disutility.\nDecision Analysis\nOrganizational Risk Maturity # Reviewed organizational risk maturity levels, security risk process maturity, and how organizational culture and structure affect risk management.\nRisk Maturity\nCyber Risk Assessment # Completed a group risk assessment involving a fictional individual, credential assets, a cyber adversary, phishing, malware, social engineering, weak cyber hygiene, and risk treatment recommendations.\nThreat Modeling\nTeam Risk Assessment Scenario # The group project analyzed a fictional cyber risk scenario involving:\na protector named Neo critical online assets such as usernames, passwords, and security question answers a cyber adversary named Agent Smith phishing attacks malware ransomware social engineering weak cyber hygiene lack of MFA active use of online platforms financial information exposure personal information exposure identity theft concerns credential compromise risk The project treated Neo’s credentials as the primary asset because compromised usernames, passwords, and security questions could unlock other services, expose financial information, enable identity theft, or support broader digital compromise.\nThe adversary was modeled as a skilled cybercriminal using phishing, malware, and social engineering. The risk assessment then considered how poor cyber hygiene increased likelihood and impact.\nRisk Analysis Workflow # 1 Define the Risk Context # Established the protector, asset, threat actor, situation, online behavior, and digital environment.\nContext\n2 Identify Threats and Vulnerabilities # Analyzed phishing, malware, ransomware, social engineering, weak cyber hygiene, weak authentication, and high online exposure.\nThreat Review\n3 Assess Likelihood and Consequence # Evaluated the likelihood of adverse events and the potential impact to credentials, personal data, financial information, and identity.\nRisk Rating\n4 Prioritize and Rank Risks # Used risk ranking and weighted ranking concepts to compare outcomes, opportunity value, and negative disutility.\nPrioritization\n5 Recommend Controls # Proposed practical risk treatment options such as MFA, audits, vulnerability assessments, secure browsing, training, monitoring, and expert consultation.\nTreatment\n6 Account for Residual Risk # Recognized that risk remains after controls are implemented and that continuous monitoring and adaptation are required.\nResidual Risk\nAnalytic Confidence # Analytic confidence was a major theme in the course.\nThe coursework framed analytic confidence as the analyst’s degree of confidence in:\nthe information available the quality of the evidence the methods used the reasoning process the reliability of sources the level of collaboration the analyst’s expertise the complexity of the task time pressure the final assessment The professional lesson is that analysts should not only state what they believe, but also communicate how confident they are and why. This improves transparency, helps decision makers weigh conclusions, and creates a kind of accountability trail.\nIn cybersecurity, this matters because alerts, indicators, vulnerability scores, user reports, threat intelligence, and forensic findings often vary in reliability.\nSource Credibility and Evidence Review # The course also emphasized competence and credibility of intelligence sources.\nThe evidence-related work distinguished between:\ntangible evidence, such as documents, objects, images, logs, or other physical/digital artifacts testimonial evidence, which depends on statements and the credibility or competence of the person providing information Important evaluation factors included:\nauthenticity chain of custody source reliability source competence source credibility whether evidence truly confirms a claim how much inferential weight the evidence should receive This maps directly to cybersecurity investigations where analysts must decide whether logs, screenshots, user reports, endpoint alerts, files, or threat intelligence are trustworthy enough to support action.\nRisk Matrix Evaluation # The course included analysis of risk matrices and their limitations.\nRisk matrices can help communicate risk by comparing likelihood and impact, but they should not be treated as perfect decision-making tools.\nThe coursework emphasized that risk matrices can be useful for visibility and communication, but they may also introduce problems such as:\nfalse precision misleading color-based interpretation weak support for resource allocation poor priority ranking overconfidence in simplified categories inconsistent interpretation across stakeholders The professional lesson is that a risk matrix can help organize risk discussions, but analysts should not let the matrix replace judgment, evidence quality, or cost-benefit analysis.\nWeighted Ranking and Decision Analysis # The weighted ranking assignment practiced structured comparison of alternatives.\nThe work included:\nidentifying possible opportunities defining positive outcomes comparing outcomes through pairwise ranking considering possible scenarios defining negative outcomes comparing disutility ranking by overall value and risk The professional relevance is that cybersecurity leaders often need to compare imperfect options:\nwhich control to implement first which vulnerability to prioritize which risk to accept which project provides the most security value which business impact matters most which scenario produces the greatest negative consequence Weighted ranking supports more transparent decision-making when resources are limited.\nOrganizational Risk Maturity # The organizational risk maturity work examined how security risk processes mature over time.\nThe course connected risk maturity to:\norganizational structure organizational culture external versus internal process ownership management process maturity embedding security processes into operations PDCA-style improvement day-to-day security management risk process independence operational integration The key lesson is that risk management is not just a document or assessment. Mature risk management becomes part of daily operations and organizational decision-making.\nThis is important for ServiceNow and GRC because platforms and workflows only work well when the organization has the maturity to use them consistently.\nRisk Treatment and Controls # The group assessment recommended practical controls for reducing risk exposure.\nControl Area Risk Treatment Purpose Risk Reduced Multi-Factor Authentication Reduce likelihood that stolen credentials alone can compromise accounts. Identity Risk Regular Security Audits Review account security, software updates, device hygiene, and password practices on a recurring schedule. Control Review Risk Assessments Identify and prioritize risk annually or when the environment changes. Prioritization Vulnerability Assessments Scan for weaknesses and misconfigurations on a more frequent schedule. Exposure Review Penetration Testing Use expert review to validate whether security controls are effective. Validation Secure Browsing Practices Use safer browsing habits, privacy tools, and caution around links, attachments, and unknown platforms. User Risk Training and Awareness Improve cyber hygiene, phishing recognition, password practices, and understanding of online threats. Human Risk Continuous Monitoring Track behavior and risk indicators over time so controls can adapt to changing threats. Residual Risk Monitoring Plan # The group project recognized that risk treatment is not complete after controls are implemented.\nThe monitoring plan included concepts such as:\nrecurring security audits digital footprint tracking behavioral monitoring training and awareness reporting and feedback adapting to new and emerging threats continuing to reduce residual risk reassessing controls as behavior and exposure change This is a strong GRC lesson: risk management should be dynamic. Controls need ongoing review, not one-time deployment.\nCapability-to-Evidence Map # Capability Evidence from SRA 311 Status Risk Analysis Analyzed cyber risk scenarios involving assets, threats, vulnerabilities, likelihood, impact, treatment, residual risk, and monitoring. Completed Analytic Confidence Explored how analysts express confidence in judgments based on evidence quality, source reliability, method use, expertise, and uncertainty. Completed Source Credibility Evaluated tangible evidence, testimonial evidence, authenticity, chain of custody, competence, credibility, and evidentiary weight. Completed Decision Analysis Used risk matrix critique, pairwise comparison, weighted ranking, and value/disutility thinking to support structured decision-making. Completed Threat Modeling Modeled a cyber adversary using phishing, malware, ransomware, and social engineering against a protector with weak cyber hygiene. Completed Risk Treatment Planning Recommended MFA, audits, risk assessments, vulnerability assessments, penetration testing, secure browsing, awareness training, and monitoring. Completed What I Learned # This course reinforced several lessons that matter in cybersecurity and GRC:\nrisk analysis must account for uncertainty evidence quality matters as much as evidence quantity source credibility affects the strength of an assessment analytic confidence should be communicated clearly risk matrices can help visualize risk but can also mislead weighted ranking can make decision tradeoffs more explicit security controls should be chosen based on risk treatment goals residual risk remains even after controls are implemented monitoring and reassessment are part of risk management cyber hygiene is a major driver of individual and organizational risk threat modeling helps connect adversary capability, target vulnerability, and potential impact risk communication must be understandable to decision makers Professional Relevance # This project supports roles involving:\nGRC risk analysis vulnerability management cybersecurity analysis ServiceNow SecOps consulting security operations incident response planning policy and control recommendations threat modeling executive risk communication security awareness and cyber hygiene planning It is especially relevant to ServiceNow SecOps and Vulnerability Response because risk-based prioritization is central to deciding what should be remediated first, what can be accepted, what needs escalation, and what evidence supports the decision.\nRelationship to Other Portfolio Projects # SRA 311 complements several other portfolio areas.\nRelated Project How It Connects Angle IST 456 IST 456 applies security risk management through SIEM investigations, ransomware, compromised credentials, data exfiltration, policy, and contingency planning. Security Risk IST 432 IST 432 connects cyber law, privacy, legal risk, digital governance, and compliance interpretation to cybersecurity decisions. Cyber Law / GRC CYBER 342W CYBER 342W focuses on incident response planning, NIST lifecycle, CSIRT governance, communication, disaster recovery, and business continuity. IR Planning ServiceNow SecOps Lab Hub ServiceNow SecOps connects risk analysis to workflow, vulnerable item prioritization, remediation ownership, validation, exception handling, and closure. SecOps Workflow Portfolio-Safe Redaction Notes # This case study intentionally excludes:\nraw academic submissions full group reports complete ranking worksheets private student identifiers full assignment answers private course materials complete source evaluation responses copy-paste-ready academic work The goal is to show risk analysis, decision analysis, source evaluation, and GRC-style reasoning without publishing raw academic work.\nRelated Portfolio Areas # GRC and Risk Analysis # This course supports governance, risk, and compliance work through risk assessment, risk treatment, source credibility, analytic confidence, and monitoring concepts.\nGRC\nVulnerability Management # Risk ranking, residual risk, and treatment planning are directly relevant to vulnerability prioritization and remediation decisions.\nVulnerability Risk\nServiceNow SecOps # Risk analysis supports assignment, prioritization, exception handling, remediation ownership, validation, and communication in SecOps workflows.\nSecOps-Relevant\nSecurity Operations # Evidence credibility, analytic confidence, and risk communication help analysts explain what they know, how confident they are, and what should happen next.\nSOC-Relevant\nNext Steps # This project can later be connected to:\na GRC capability section a risk analysis review path ServiceNow Vulnerability Response risk-prioritization notes a risk matrix critique concept note a residual risk and exception-handling concept a threat modeling checklist an analytic confidence checklist an evidence credibility checklist For now, this page serves as the main portfolio-safe summary of my SRA 311 Risk Analysis in a Security Context work.\n","date":"5 June 2026","externalUrl":null,"permalink":"/projects/sra-311-risk-analysis-security-context/","section":"Projects","summary":"","title":"SRA 311: Risk Analysis in a Security Context","type":"projects"},{"content":"","date":"5 June 2026","externalUrl":null,"permalink":"/tags/structured-analysis/","section":"Tags","summary":"","title":"Structured Analysis","type":"tags"},{"content":"","date":"5 June 2026","externalUrl":null,"permalink":"/tags/swing/","section":"Tags","summary":"","title":"Swing","type":"tags"},{"content":"","date":"5 June 2026","externalUrl":null,"permalink":"/tags/","section":"Tags","summary":"","title":"Tags","type":"tags"},{"content":"","date":"5 June 2026","externalUrl":null,"permalink":"/tags/team-collaboration/","section":"Tags","summary":"","title":"Team Collaboration","type":"tags"},{"content":"","date":"5 June 2026","externalUrl":null,"permalink":"/tags/technical-documentation/","section":"Tags","summary":"","title":"Technical Documentation","type":"tags"},{"content":"","date":"5 June 2026","externalUrl":null,"permalink":"/tags/testing/","section":"Tags","summary":"","title":"Testing","type":"tags"},{"content":"","date":"5 June 2026","externalUrl":null,"permalink":"/tags/threat-modeling/","section":"Tags","summary":"","title":"Threat Modeling","type":"tags"},{"content":"","date":"5 June 2026","externalUrl":null,"permalink":"/tags/usability-testing/","section":"Tags","summary":"","title":"Usability Testing","type":"tags"},{"content":"","date":"5 June 2026","externalUrl":null,"permalink":"/tags/user-centered-design/","section":"Tags","summary":"","title":"User-Centered Design","type":"tags"},{"content":"","date":"5 June 2026","externalUrl":null,"permalink":"/tags/ux-research/","section":"Tags","summary":"","title":"UX Research","type":"tags"},{"content":"","date":"5 June 2026","externalUrl":null,"permalink":"/tags/validation/","section":"Tags","summary":"","title":"Validation","type":"tags"},{"content":"","date":"5 June 2026","externalUrl":null,"permalink":"/tags/virtualization/","section":"Tags","summary":"","title":"Virtualization","type":"tags"},{"content":"","date":"5 June 2026","externalUrl":null,"permalink":"/tags/weighted-ranking/","section":"Tags","summary":"","title":"Weighted Ranking","type":"tags"},{"content":"","date":"5 June 2026","externalUrl":null,"permalink":"/tags/winhex/","section":"Tags","summary":"","title":"WinHex","type":"tags"},{"content":"","date":"5 June 2026","externalUrl":null,"permalink":"/tags/wireshark/","section":"Tags","summary":"","title":"Wireshark","type":"tags"},{"content":"","date":"5 June 2026","externalUrl":null,"permalink":"/tags/workflow-design/","section":"Tags","summary":"","title":"Workflow Design","type":"tags"},{"content":"","date":"5 June 2026","externalUrl":null,"permalink":"/tags/workflow-modeling/","section":"Tags","summary":"","title":"Workflow Modeling","type":"tags"},{"content":"","date":"5 June 2026","externalUrl":null,"permalink":"/tags/zero-trust/","section":"Tags","summary":"","title":"Zero Trust","type":"tags"},{"content":"","date":"4 June 2026","externalUrl":null,"permalink":"/tags/ai/","section":"Tags","summary":"","title":"AI","type":"tags"},{"content":" Portfolio Gallery\nThis section explores concept notes, research ideas, and future lab work at the intersection of artificial intelligence, cybersecurity operations, vulnerability management, ServiceNow SecOps, and OT/ICS security.\nThe goal is not to present AI as a replacement for security professionals. Instead, this section focuses on how AI could support better triage, prioritization, ownership assignment, communication, and risk translation across technical and operational teams.\nAI content approach: These pages are labeled clearly as concept notes, idea-lab writeups, or future lab ideas. They are intended to show security workflow thinking without overstating them as completed production systems.\nFeatured Concept Notes # AI-Powered Vulnerability Ownership Recommender for ServiceNow SecOps # A concept design for AI-assisted vulnerable item ownership, assignment group recommendation, remediation path suggestion, escalation priority, and analyst-reviewed next steps.\nAI SecOps ServiceNow VR Using AI to Translate Vulnerability Risk Between Cybersecurity and OT Operations Teams # A concept for using AI to help translate vulnerability findings into operationally meaningful language for OT, ICS, cybersecurity, and business stakeholders.\nConcept Note OT/ICS Risk Content Types # Concept Notes # Forward-looking cybersecurity and AI ideas based on real workflow challenges, professional observations, and security operations concepts.\nIdea Lab\nFuture Labs # Planned hands-on experiments, mockups, diagrams, and prototypes that could demonstrate how an AI-assisted security workflow might work in practice.\nPlanned\nServiceNow SecOps Ideas # Concepts focused on how AI could support Vulnerability Response, vulnerable item context, ownership assignment, remediation communication, and exception documentation.\nSecOps\nFuture AI SecOps Lab Ideas # AI-Powered Vulnerability Ownership Recommender # A concept for recommending assignment groups based on vulnerable item context, CI ownership, business criticality, remediation history, and historical assignment patterns.\nPlanned Concept\nAI Vulnerable Item Context Summary # A future lab idea for summarizing vulnerable item details into analyst-reviewed context without removing human oversight.\nFuture Lab\nAnalyst Review Checkpoint # A workflow idea where AI-generated recommendations require analyst validation before communication, escalation, or remediation action.\nHuman-in-the-Loop\nOT/ICS Risk Translation # A concept for translating CVEs, severity, asset criticality, and remediation constraints into operationally meaningful language.\nOT/ICS\n","date":"4 June 2026","externalUrl":null,"permalink":"/ai-security/","section":"AI \u0026 Security","summary":"","title":"AI \u0026 Security","type":"ai-security"},{"content":"","date":"4 June 2026","externalUrl":null,"permalink":"/categories/ai--security/","section":"Categories","summary":"","title":"AI \u0026 Security","type":"categories"},{"content":"","date":"4 June 2026","externalUrl":null,"permalink":"/tags/ai-security/","section":"Tags","summary":"","title":"AI Security","type":"tags"},{"content":" AI SecOps Concept Design\nThis concept explores how an AI-assisted workflow could help ServiceNow SecOps teams recommend vulnerable item ownership, likely remediation path, escalation priority, and analyst-reviewed next steps without removing human oversight.\nType AI Security Concept Focus Vulnerability Ownership Recommendation Platform Context ServiceNow SecOps / Vulnerability Response Design Principle Human-in-the-Loop Review Outcome Faster Ownership + Better Triage Context Status Concept / Not a Production System AI-Powered Vulnerability Ownership Recommender for ServiceNow SecOps # Overview # One common challenge in vulnerability management is not simply identifying vulnerable items. The harder operational problem is making sure each finding reaches the correct owner with enough context to support action.\nThis concept proposes an AI-assisted workflow for ServiceNow SecOps and Vulnerability Response that helps recommend:\nlikely assignment group likely remediation owner recommended remediation path escalation priority exception or false-positive likelihood missing context that an analyst should verify analyst-reviewed next step The goal is not to replace security analysts, remediation teams, or asset owners. The goal is to reduce ownership confusion, improve triage consistency, and help security teams move findings toward accountable remediation faster.\nProblem # Vulnerability Response workflows can slow down when ownership is unclear.\nA vulnerable item may include technical details such as CVE, affected CI, scanner source, severity, and detection evidence, but the workflow still depends on answering practical operational questions:\nWho owns this asset? Which team can actually remediate it? Is the assignment group accurate? Is the asset mapped to the correct application or service? Is this vulnerability patchable? Does remediation require a change window? Is this a duplicate, false positive, exception candidate, or urgent escalation? Is the business impact clear enough to prioritize? When this context is missing or inconsistent, vulnerable items can bounce between teams, sit unassigned, or remain open without clear accountability.\nConcept # The AI-Powered Vulnerability Ownership Recommender would act as a decision-support layer inside or alongside a ServiceNow SecOps workflow.\nIt would review vulnerable item context and recommend a likely owner and next action based on structured signals.\nPotential input signals could include:\nvulnerable item details affected CI CMDB ownership support group mapping application or business service relationship asset criticality vulnerability severity exploitability context exposure context historical assignment patterns remediation history exception history false-positive patterns previous closure notes SLA or risk scoring context The recommender would generate a recommendation, but the final action would require analyst review.\nWorkflow Map # 1 Vulnerable Item Context # The workflow starts with vulnerable item details such as CVE, affected CI, risk score, scanner source, severity, and asset information.\nInput Context\n2 Ownership Signal Review # The system reviews CMDB ownership, support groups, assignment history, service relationships, and past remediation patterns.\nOwnership Signals\n3 AI Recommendation # The system recommends likely assignment group, remediation owner, escalation priority, and suggested next step.\nAI Recommendation\n4 Analyst Review # A security analyst reviews the recommendation, confirms context, adjusts ownership if needed, and approves or rejects the suggestion.\nHuman Review\n5 Workflow Action # After approval, the vulnerable item is assigned, escalated, routed for remediation, or sent through an exception / false-positive review path.\nAction\n6 Feedback Loop # Final assignment, remediation outcome, closure reason, and analyst correction become feedback signals for future recommendations.\nContinuous Improvement\nRecommendation Output # A useful recommendation should be explainable and reviewable.\nExample output structure:\nRecommended assignment group: Confidence level: Reasoning: Relevant CI ownership signals: Historical assignment pattern: Suggested remediation path: Potential blocker: Escalation priority: Analyst checks required: Recommended next step: This format is intentionally designed for analyst review. The recommendation should show why it was generated, not just produce an answer.\nHuman-in-the-Loop Controls # This concept should require analyst approval before taking meaningful workflow action.\nImportant controls:\nAI should not automatically close vulnerable items. AI should not automatically approve exceptions. AI should not override analyst judgment. AI should show reasoning and uncertainty. AI should highlight missing context. AI should preserve auditability. AI recommendations should be logged. Analyst corrections should be captured as feedback. The goal is recommendation support, not autonomous vulnerability management.\nConcept Map # Vulnerable Item # CVE, risk score, affected CI, scanner source, asset context, severity, and detection evidence.\nFinding\nOwnership Signals # CMDB owner, support group, business service, application mapping, and historical assignments.\nRouting\nRemediation Context # Patchability, maintenance windows, change requirements, compensating controls, and remediation notes.\nAction Path\nRisk Context # Exploitability, exposure, business criticality, operational impact, and SLA pressure.\nPrioritization\nAnalyst Review # Human validation, decision approval, assignment correction, and documentation.\nControl Point\nFeedback Loop # Outcome history, closure reason, analyst corrections, assignment accuracy, and exception patterns.\nLearning Signal\nExample Use Case # A vulnerable item is detected on a server tied to a business application.\nThe scanner identifies the vulnerability, but the assignment group is missing or uncertain. The recommender reviews the CI relationship, application ownership, previous vulnerable item assignments, historical remediation tasks, and closure notes.\nThe system recommends:\nassignment group likely responsible for the affected CI remediation path based on previous similar findings escalation priority based on asset criticality and exploitability analyst checks needed before assignment The analyst reviews the recommendation, confirms the affected service and owner, and approves assignment.\nThe workflow moves faster because the analyst receives structured context instead of manually piecing together ownership from scattered records.\nPotential Benefits # This concept could help improve:\nassignment accuracy triage consistency remediation accountability vulnerable item routing analyst efficiency stakeholder communication exception review quality risk-based prioritization documentation quality repeatability across similar findings Risks and Limitations # This concept also has important risks.\nPotential risks include:\nrecommending the wrong owner over-relying on historical assignment patterns reinforcing bad CMDB data missing operational context recommending action based on incomplete records confusing confidence with correctness creating automation bias exposing sensitive asset or vulnerability context if poorly governed These risks are why the concept should use analyst review, explainable recommendations, and audit logging.\nData Quality Requirements # This concept would only be useful if underlying data is reasonably trustworthy.\nImportant data quality areas include:\naccurate CMDB ownership reliable CI relationships maintained support groups useful assignment history clear remediation notes consistent closure reasons documented exception records accurate vulnerability source data asset criticality mapping Poor data quality would reduce recommendation accuracy and could make the system misleading.\nServiceNow SecOps Relevance # This concept aligns with practical ServiceNow SecOps work because Vulnerability Response is not only a technical vulnerability repository. It is also a workflow system for assigning, tracking, documenting, validating, and closing security work.\nAn AI-assisted recommender would be most useful when it supports the workflow layer:\nwho should own the item what context matters what action is likely needed what evidence should be checked when escalation is appropriate when exception review may be needed Portfolio Note # This is a concept design, not a production system.\nIt is included to demonstrate ServiceNow SecOps workflow thinking, AI security ideation, vulnerability management process understanding, and human-in-the-loop design principles. It does not claim that a working enterprise product was built, deployed, or tested.\n","date":"4 June 2026","externalUrl":null,"permalink":"/ai-security/ai-powered-vulnerability-ownership-recommender/","section":"AI \u0026 Security","summary":"","title":"AI-Powered Vulnerability Ownership Recommender for ServiceNow SecOps","type":"ai-security"},{"content":"","date":"4 June 2026","externalUrl":null,"permalink":"/tags/blowfish/","section":"Tags","summary":"","title":"Blowfish","type":"tags"},{"content":"","date":"4 June 2026","externalUrl":null,"permalink":"/tags/cloudflare-pages/","section":"Tags","summary":"","title":"Cloudflare Pages","type":"tags"},{"content":"","date":"4 June 2026","externalUrl":null,"permalink":"/tags/github/","section":"Tags","summary":"","title":"GitHub","type":"tags"},{"content":"","date":"4 June 2026","externalUrl":null,"permalink":"/tags/hugo/","section":"Tags","summary":"","title":"Hugo","type":"tags"},{"content":"","date":"4 June 2026","externalUrl":null,"permalink":"/tags/ot/ics/","section":"Tags","summary":"","title":"OT/ICS","type":"tags"},{"content":"","date":"4 June 2026","externalUrl":null,"permalink":"/tags/portfolio/","section":"Tags","summary":"","title":"Portfolio","type":"tags"},{"content":"","date":"4 June 2026","externalUrl":null,"permalink":"/categories/research--labs/","section":"Categories","summary":"","title":"Research \u0026 Labs","type":"categories"},{"content":"Research \u0026amp; Labs\nThis section is for hands-on lab work and technical notes.\nThe project gallery has the full course-coded evidence map. This page is narrower: ServiceNow SecOps workflow work, malware/security labs, and the technical lab collections that best show how I work through systems, evidence, and process.\nHow to read this section: Start with ServiceNow SecOps if you are reviewing role fit. Start with CYBER 366 if you want malware analysis. Start with CYBER 262 or IST 451 if you want broader security foundations.\nStart Here # ServiceNow SecOps Lab Hub # This is the most career-aligned lab section. It focuses on Vulnerability Response workflow: vulnerable item triage, ownership, remediation tracking, validation, exceptions, and closure.\nThis is where I would send someone first for ServiceNow SecOps or Vulnerability Response conversations.\nPrimary Focus ServiceNow SecOps ServiceNow VR Triage Checklist # A practical checklist for thinking through vulnerable item intake, risk review, assignment group ownership, remediation path, exception handling, validation, and closure.\nThis is shorter than the lab hub and easier to review quickly.\nVulnerability Response Checklist Malware and Security Lab Collections # CYBER 366: Malware Analytics \u0026amp; Reverse Engineering Lab Collection # This is the strongest malware-analysis lab collection in the portfolio.\nIt covers static analysis, dynamic analysis, packed executables, UPX, FLOSS, PE inspection, ProcMon, RegShot, IDA Pro, Ghidra, Binary Ninja, anti-debugging behavior, and keylogging indicators.\nMalware Analysis Reverse Engineering CYBER 262: Security Foundations Lab Collection # A hands-on security foundations collection covering Linux log analysis, Python parsing, endpoint protection, Wazuh HIDS, Snort NIDS, Splunk, two-factor authentication, and buffer overflow concepts.\nThis page shows the base layer behind later malware, forensics, and incident response work.\nSecurity Foundations Hands-On Labs IST 451: Security Labs Collection # A broader security lab collection covering service identification, Apache hardening, OpenVAS, SQL injection concepts, malware analysis, IDS concepts, wireless security, and privilege escalation concepts.\nThis is a supporting lab collection, not the first page I would send someone to, but it adds useful breadth.\nSecurity Labs Vulnerability Analysis What This Section Shows # Area Evidence Why It Matters ServiceNow SecOps SecOps lab hub and VR triage checklist. Primary Career Fit Vulnerability Response Workflow thinking around vulnerable item review, assignment, remediation, exception handling, validation, and closure. VR Workflow Malware Analysis CYBER 366 lab work with static analysis, dynamic analysis, unpacking, reverse-engineering tools, and behavior interpretation. Technical Depth Detection Foundations Wazuh, Snort, Splunk, endpoint protection, logs, IDS concepts, and security monitoring foundations. SOC-Relevant Security Lab Breadth Web security, vulnerability scanning, IDS concepts, wireless security, malware investigation, and privilege escalation concepts from IST 451. Supporting Evidence Tools Referenced in These Labs # This is not a mastery claim for every tool. It is a map of tools I used or studied in the lab work summarized here.\nTool / Concept Used For Evidence ServiceNow SecOps / VR Vulnerable item triage, ownership routing, remediation workflow, validation, exception handling, and closure thinking. SecOps Hub PEiD, UPX, FLOSS Executable metadata review, packed executable identification, unpacking, decoded strings, and stack-string review. CYBER 366 ProcMon, RegShot, Process Explorer Dynamic analysis, process behavior, registry activity, file-system writes, and clean-state comparison. CYBER 366 IDA Pro, Ghidra, Binary Ninja Disassembly, decompilation, function review, string references, imported API interpretation, and control-flow reasoning. CYBER 366 Wazuh, Snort, Splunk Host-based detection, network intrusion detection, log review, alerting concepts, and SIEM-style investigation foundations. CYBER 262 OpenVAS, Apache, SQL Injection Concepts Service identification, web server hardening, vulnerability scanning, SQL injection concepts, and defensive security lab work. IST 451 Lab-Heavy Work Outside This Section # Some of the strongest hands-on work lives under Projects instead of Research \u0026amp; Labs because those pages are bigger than a simple lab note.\nCYBER 440 Capstone # The best incident response and forensic investigation story in the portfolio.\nFlagship\nIST 454 Computer \u0026amp; Cyber Forensics # Forensic imaging, hash verification, registry analysis, data carving, and deleted file recovery.\nForensics\nIST 456 Security \u0026amp; Risk Management # Enigma Glass SIEM-style labs covering ransomware, compromised credentials, and data exfiltration.\nRisk + SOC\nSRA 221 Information Security Foundations # Earlier security-tool exposure: OWASP ZAP, Wireshark, SPARTA, OpenVPN, pfSense, Active Directory, forensics, and Splunk.\nFoundational\nHow I Treat Lab Writeups # Keep the Method # I summarize the workflow, tools, findings, and lessons learned.\nMethod\nRemove the Sensitive Parts # I do not publish raw submissions, malware samples, private screenshots, credentials, exact lab artifacts, or full solution steps.\nRedacted\nConnect It to Roles # The goal is not to show that I completed a class. The goal is to show what the work proves about how I investigate, document, and think through security problems.\nEvidence\nQuick Actions # ServiceNow SecOps CYBER 366 Malware CYBER 262 Foundations Projects ","date":"4 June 2026","externalUrl":null,"permalink":"/research-labs/","section":"Research \u0026 Labs","summary":"","title":"Research \u0026 Labs","type":"research-labs"},{"content":"","date":"4 June 2026","externalUrl":null,"permalink":"/tags/secops/","section":"Tags","summary":"","title":"SecOps","type":"tags"},{"content":"","date":"4 June 2026","externalUrl":null,"permalink":"/tags/security/","section":"Tags","summary":"","title":"Security","type":"tags"},{"content":"","date":"4 June 2026","externalUrl":null,"permalink":"/tags/security-operations/","section":"Tags","summary":"","title":"Security Operations","type":"tags"},{"content":"","date":"4 June 2026","externalUrl":null,"permalink":"/tags/servicenow/","section":"Tags","summary":"","title":"ServiceNow","type":"tags"},{"content":"","date":"4 June 2026","externalUrl":null,"permalink":"/tags/servicenow-secops/","section":"Tags","summary":"","title":"ServiceNow SecOps","type":"tags"},{"content":" ServiceNow SecOps Lab Hub # Content Type: Hands-On Lab Hub / ServiceNow SecOps Portfolio\nThis lab hub documents personal lab work, workflow notes, and portfolio-safe ServiceNow SecOps concepts. It does not include client data, proprietary implementation details, internal company screenshots, or confidential configuration information.\nOverview # This lab hub is focused on ServiceNow Security Operations, especially Vulnerability Response and vulnerability management workflows.\nThe goal is to document how vulnerable items move from detection and review into ownership assignment, remediation tracking, validation, exception handling, and closure.\nThis section is designed to show practical understanding of ServiceNow SecOps concepts beyond a resume bullet point.\nWhy This Matters # Vulnerability management is not only about identifying findings. It is about turning findings into accountable, trackable, risk-informed remediation work.\nA strong Vulnerability Response process should help answer:\nWhat vulnerability was identified? Which asset or configuration item is affected? How severe is the risk? Who owns remediation? What action is required? Is an exception needed? Was remediation completed? Was the finding validated before closure? ServiceNow SecOps can help organize this process by connecting vulnerability data, asset context, workflow states, assignment groups, tasks, and reporting.\nCurrent Lab Focus # Vulnerability Response Workflow # The current lab focus is an end-to-end Vulnerability Response workflow from vulnerable item review to closure.\nDedicated case study:\nServiceNow Vulnerability Response Lab: From Finding to Closure\nThis lab demonstrates:\nvulnerable item intake triage and investigation assignment group ownership remediation task concepts exception and false positive handling validation before closure analyst documentation Vulnerability Response Workflow Map # 1 Intake # Vulnerable items are reviewed as findings enter the workflow from scanning, import, integration, or manual review.\nFinding Review\n2 Triage # Risk, asset context, severity, exploitability, business impact, and remediation urgency are evaluated.\nRisk Review\n3 Ownership # The vulnerable item is assigned to the correct remediation group or owner based on CI, service, application, or support responsibility.\nAssignment\n4 Remediation # A remediation task or action path is tracked so the finding becomes accountable work instead of an unresolved security observation.\nAction Tracking\n5 Exception Handling # Findings that cannot be immediately remediated may require risk acceptance, compensating controls, maintenance-window planning, or false-positive review.\nException Logic\n6 Validation \u0026amp; Closure # Closure should be based on documented evidence that remediation occurred, risk was accepted, or the finding was otherwise resolved.\nClosure\nServiceNow SecOps Concepts Covered # Vulnerable Items # Vulnerable items represent findings that need review, prioritization, ownership, remediation, or exception handling.\nAssignment Groups # Assignment groups help route remediation work to the correct team or owner. Clear assignment is critical because unowned findings often become unresolved risk.\nRemediation Tasks # Remediation tasks help convert security findings into actionable work. This supports accountability and gives remediation teams a clearer path to closure.\nException Handling # Not every vulnerability can be immediately remediated. Some findings may require risk acceptance, vendor review, maintenance-window planning, compensating controls, or false positive validation.\nValidation and Closure # Closure should be based on evidence. A strong process should confirm that remediation happened and that the final state is documented.\nLab Roadmap # Future lab writeups may include:\nBuilding sample vulnerable item data for a ServiceNow SecOps lab\nDesigning assignment group logic for Vulnerability Response\nCreating a vulnerability triage checklist\nMapping vulnerable item states to analyst actions\nException handling and risk acceptance workflow concepts\nServiceNow Vulnerability Response reporting ideas\nAI-assisted vulnerability ownership recommendation concept\nAI-generated analyst summary for vulnerable item review\nTranslating vulnerable item risk into stakeholder communication\nServiceNow Vulnerability Response Triage Checklist\nProfessional Relevance # This lab hub supports my focus on:\nServiceNow SecOps Vulnerability Response vulnerability management security operations workflow design remediation ownership risk-based prioritization analyst communication AI-assisted SecOps workflow ideas Portfolio Note # This section is intentionally written as a portfolio-safe lab hub.\nIt is not a client implementation walkthrough, and it does not publish proprietary configuration, internal documents, or confidential screenshots. The purpose is to demonstrate practical understanding of ServiceNow SecOps and vulnerability management workflows in a clean, employer-facing format.\n","date":"4 June 2026","externalUrl":null,"permalink":"/research-labs/servicenow-secops-lab-hub/","section":"Research \u0026 Labs","summary":"","title":"ServiceNow SecOps Lab Hub","type":"research-labs"},{"content":" Portfolio Case Study\nThis case study summarizes a portfolio-safe ServiceNow Vulnerability Response lab focused on moving a vulnerable item from review through ownership, remediation planning, validation, and closure.\nType ServiceNow SecOps Lab Focus Vulnerability Response Workflow Role Analyst / Workflow Designer Platform ServiceNow PDI / SecOps Concepts Outcome Finding-to-Closure Workflow Privacy Level Portfolio-Safe / No Client Data ServiceNow Vulnerability Response Lab: From Finding to Closure # Content Type: Hands-On Lab / Portfolio Project\nThis project is based on a personal ServiceNow lab environment and sanitized demonstration workflow. It does not include client data, internal company information, proprietary implementation details, or confidential screenshots.\nOverview # This lab demonstrates an end-to-end Vulnerability Response workflow in ServiceNow, focused on how a vulnerable item moves from initial review to ownership assignment, remediation tracking, validation, and closure.\nThe goal of this project is to show practical understanding of vulnerability management workflows, ServiceNow SecOps concepts, and the operational process behind turning vulnerability findings into assigned, trackable remediation work.\nProblem # Vulnerability management programs often struggle when findings are not clearly assigned, prioritized, tracked, or validated.\nA vulnerability record by itself is not enough. Security teams need a workflow that answers:\nWhat is the vulnerability? Which asset or configuration item is affected? Who owns remediation? How should risk be prioritized? What task or action is required? Was remediation completed? Has the finding been validated before closure? ServiceNow Vulnerability Response helps structure this process by connecting vulnerability data, asset context, ownership, remediation tasks, and workflow states.\nLab Environment # This project was created using a ServiceNow personal developer/lab environment with Vulnerability Response functionality enabled.\nThe lab included:\nVulnerability Response plugin/functionality Sample vulnerable item data Configuration item references Assignment groups Risk and severity fields Vulnerable item lifecycle states Remediation task workflow concepts Sample data was created for demonstration purposes only.\nMy Role # For this lab, I acted as both the security analyst and workflow reviewer.\nMy responsibilities included:\nPreparing the ServiceNow lab environment Creating sample vulnerability data Reviewing vulnerable item records Demonstrating triage and investigation steps Assigning ownership to remediation teams Explaining remediation task flow Walking through validation and closure logic Translating the workflow into a clear portfolio case study Workflow Demonstrated # 1. Vulnerability Intake # The workflow begins with a vulnerable item representing a vulnerability affecting a configuration item.\nKey fields reviewed include:\nVulnerability or CVE summary Affected configuration item Risk rating or severity Assignment group Current state Remediation guidance Asset or business context where available 2. Triage and Investigation # During triage, the analyst reviews whether the finding is actionable and determines what additional context is needed.\nImportant questions include:\nIs the affected asset still active? Is the vulnerability relevant to the environment? Is the risk rating appropriate? Is there known exploit activity? Is the system internet-facing or business-critical? Is there already a remediation path? 3. Ownership Assignment # Once reviewed, the vulnerable item needs a clear owner.\nIn this lab, ownership is represented through assignment groups and assigned users. This supports accountability and helps ensure that remediation work is not left untracked.\n4. Remediation Task Flow # The workflow can move from a vulnerable item into a remediation task or implementation step.\nExample remediation paths include:\nApply vendor patch Upgrade affected software Decommission vulnerable system Apply configuration change Add compensating control Request exception if remediation is not immediately possible 5. Exception or False Positive Handling # Not every finding should immediately move to closure.\nSome findings may require:\nException request Risk acceptance Vendor dependency review Maintenance window planning False positive validation Compensating control documentation A strong vulnerability response process needs to handle these cases without losing visibility.\n6. Validation and Closure # Before closure, remediation should be validated.\nClosure should answer:\nWas the vulnerability actually remediated? Was the system rescanned or otherwise validated? Was the closure reason documented? Is there evidence supporting the final state? This helps prevent premature closure and supports auditability.\nWhat This Lab Demonstrates # This project demonstrates understanding of:\nServiceNow Vulnerability Response concepts Vulnerable item lifecycle Security operations workflow design Remediation ownership Assignment group logic Risk-based vulnerability management Exception and false positive handling Analyst review and documentation Translating technical findings into operational work Lessons Learned # A vulnerability response workflow is only effective when ownership, context, and follow-through are clear.\nThe most important part of the process is not simply importing vulnerability data. The value comes from turning findings into assigned work, tracking remediation, validating outcomes, and documenting decisions.\nThis lab reinforced the importance of clear workflow design, accurate asset context, and communication between security teams and remediation owners.\nWhat I Would Improve # With more time, I would expand this lab by adding:\nMore realistic asset criticality data Additional assignment groups A mock CMDB relationship model Example exception approval flow Screenshots with sensitive values removed Dashboard-style reporting for vulnerable item status A small AI-assisted ownership recommendation concept Portfolio Note # This project is intentionally summarized as a redacted lab case study. The purpose is to show hands-on understanding of ServiceNow Vulnerability Response and vulnerability management workflows without exposing private implementation details or sensitive data.\n","date":"4 June 2026","externalUrl":null,"permalink":"/projects/servicenow-vulnerability-response-lab/","section":"Projects","summary":"","title":"ServiceNow Vulnerability Response Lab: From Finding to Closure","type":"projects"},{"content":" ServiceNow SecOps Checklist\nThis checklist summarizes a portfolio-safe approach for reviewing vulnerable items in a ServiceNow Vulnerability Response workflow. It is designed to show practical triage thinking around risk, ownership, remediation, exceptions, validation, and closure.\nType SecOps Process Checklist Focus Vulnerable Item Triage Platform ServiceNow Vulnerability Response Audience Security Analysts / Remediation Owners Outcome Structured Finding-to-Closure Review Privacy Level Portfolio-Safe / No Client Data ServiceNow Vulnerability Response Triage Checklist # Overview # A vulnerable item should not be treated as a static finding. It should be reviewed as a piece of operational security work that needs risk context, ownership, remediation direction, validation, and clear documentation.\nThis checklist organizes the review process into practical triage stages.\n1. Vulnerable Item Intake # Initial review should confirm what entered the workflow and whether the finding has enough context to be actionable.\nReview questions:\nWhat vulnerability or finding was identified? What asset, CI, host, application, or service is affected? Is the finding tied to a known CVE or vulnerability entry? Is severity or risk rating available? Is scan/source information available? Is this a duplicate, reopened, or newly observed finding? Is the affected asset still active and relevant? Intake Context Review 2. Risk and Priority Review # Triage should go beyond raw severity. A high-severity finding on a non-critical asset may not carry the same operational priority as a medium-severity finding on an exposed critical system.\nReview questions:\nWhat is the technical severity? Is exploitability known or likely? Is the asset internet-facing or externally reachable? Is the affected CI business-critical? Is there known active exploitation? Is the vulnerability tied to ransomware, privilege escalation, remote code execution, or lateral movement risk? Does the asset support an important business or operational function? Are compensating controls already in place? Risk Review Business Context 3. Ownership Assignment # A vulnerability without clear ownership often becomes unresolved risk. Assignment should be based on asset ownership, service responsibility, support group mapping, or remediation accountability.\nReview questions:\nWhich team owns the affected CI or service? Is there a support group mapped to the CI? Is the assignment group accurate? Is the assigned team responsible for remediation or only review? Is escalation needed because ownership is unclear? Is the remediation owner different from the business owner? Is there enough information for the owner to act? Ownership Assignment Group 4. Remediation Path # The triage process should identify what action is expected and whether a remediation task, change, patching activity, configuration update, or exception path is needed.\nReview questions:\nIs a patch, upgrade, configuration change, or compensating control required? Is remediation feasible immediately? Does the fix require a maintenance window? Is change approval required? Is the remediation action clear enough for the assigned team? Is there a remediation deadline or SLA? Should a remediation task be created or updated? Are implementation notes documented? Remediation Action Tracking 5. Exception and False Positive Review # Not every finding can be remediated immediately. Some require risk acceptance, compensating controls, vendor review, or false-positive validation.\nReview questions:\nIs the finding a confirmed vulnerability? Could this be a false positive? Is the vulnerable software actually installed or reachable? Is the affected asset out of scope, retired, or decommissioned? Is remediation blocked by business, vendor, compatibility, or operational constraints? Is risk acceptance required? Are compensating controls documented? Is an expiration/review date required for the exception? Exception Logic Risk Acceptance 6. Validation and Closure # Closure should be evidence-based. A vulnerable item should not be closed only because someone says remediation happened.\nReview questions:\nWas remediation completed? Was the finding rescanned or otherwise validated? Is there evidence of patching, configuration change, mitigation, or risk acceptance? Is the final state documented? Was the correct closure reason selected? Are notes clear enough for audit or later review? If exception-based, is the review date documented? If false positive, is the reasoning documented? Validation Closure Evidence Analyst Notes Template # A useful vulnerable item note should be concise, factual, and action-oriented.\nExample structure:\nFinding: Affected asset / CI: Risk context: Assigned owner: Expected remediation: Current blocker: Validation method: Closure / next step: Why This Checklist Matters # This checklist supports a more mature Vulnerability Response process by helping move findings from raw technical observations into accountable security work.\nA strong triage process improves:\nownership clarity remediation accountability risk prioritization exception consistency documentation quality validation before closure communication between security and remediation teams Portfolio Note # This checklist is intentionally generic and portfolio-safe. It does not include client data, proprietary workflows, internal screenshots, confidential assignment logic, or implementation-specific configuration.\n","date":"4 June 2026","externalUrl":null,"permalink":"/research-labs/servicenow-vr-triage-checklist/","section":"Research \u0026 Labs","summary":"","title":"ServiceNow Vulnerability Response Triage Checklist","type":"research-labs"},{"content":"","date":"4 June 2026","externalUrl":null,"permalink":"/tags/static-site/","section":"Tags","summary":"","title":"Static Site","type":"tags"},{"content":"Live Portfolio Project\nsudoRunner is not just where I publish my portfolio. It is also one of the projects.\nI built it to turn my resume, academic work, cybersecurity labs, ServiceNow SecOps direction, GRC work, incident response projects, forensics evidence, and technical writing into something a reviewer can actually navigate.\nType Professional Cybersecurity Portfolio Stack Hugo · Blowfish · GitHub · Cloudflare Pages Focus HCI · Security-Conscious Publishing · Technical Writing Deployment Cloudflare Pages + Custom Domain Brand sudoRunner Terminal-Style Identity Status Live / Iterative Why I Built This # I wanted something better than a static resume.\nA resume can list ServiceNow, vulnerability management, cybersecurity labs, incident response, forensics, malware analysis, GRC, cloud, HCI, and software coursework. But it does not show how I think, how I write, how I organize evidence, or how careful I am with sensitive material.\nThis site is meant to solve that problem.\nThe goal is simple:\nhelp a recruiter understand my fit quickly help a technical reviewer find the strongest evidence keep ServiceNow SecOps and Vulnerability Response easy to find show academic work without dumping raw submissions show technical depth without publishing sensitive files make the site usable on desktop and mobile keep the review path obvious What I Actually Built # This site includes:\na homepage with a clear Start Here path role-based review paths a capability-to-evidence map a project gallery with course-coded academic evidence a public resume page a credentials page a professional contact page a changelog a ServiceNow SecOps lab hub cybersecurity lab summaries GRC and risk analysis summaries incident response and forensics summaries OT/ICS security notes AI-assisted SecOps concept notes mobile layout fixes custom CSS and layout overrides custom favicon and branding privacy-conscious public publishing choices The result is a portfolio that is organized more like a technical product than a folder of assignments.\nArchitecture # The site uses a static deployment model.\n1 Local Hugo Site # Content, Markdown pages, layout overrides, partials, custom CSS, and static assets are maintained locally.\nLocal Build\n2 GitHub Repository # Changes are committed through Git and pushed to GitHub for version control and deployment tracking.\nVersion Control\n3 Cloudflare Pages # Cloudflare Pages builds and deploys the Hugo site from the GitHub repository.\nStatic Hosting\n4 Custom Domain # The site is served through a custom domain with Cloudflare DNS.\nDNS\n5 Public Contact Layer # Cloudflare Email Routing and a public-facing contact alias keep personal contact details off the site.\nContact Privacy\nHCI Decisions # A lot of the work on this site has been HCI work, not just design polish.\nThe biggest usability issue was that the site kept growing. As more academic projects were added, the portfolio needed stronger navigation and a clearer hierarchy.\nThe current structure is built around reviewer intent:\nProblem Design Decision Result Too many possible starting points Added a stronger homepage Start Here button and a dedicated Start Here page. Clear Entry Different reviewers care about different evidence Built role-based review paths for recruiters, ServiceNow reviewers, cybersecurity analysts, IR/forensics reviewers, GRC reviewers, OT/ICS reviewers, cloud reviewers, and HCI/software reviewers. Role-Based Paths Project list became too large Reorganized Projects by evidence strength and topic instead of treating every course artifact as equal. Hierarchy Buttons and labels looked too similar Separated clickable CTAs from static badges, honors, credentials, labels, and information panels. Click Clarity Mobile layout had visual collisions Adjusted card stacking, spacing, button behavior, safe areas, and text wrapping for smaller screens. Mobile HCI Security-Conscious Publishing # A cybersecurity portfolio has a different publishing problem than a normal design portfolio.\nA lot of my evidence involves malware labs, forensics, incident response, security tools, academic submissions, simulated environments, screenshots, credentials, and sensitive technical details. Publishing everything raw would be careless.\nSo the site uses a redacted summary approach.\nI avoid publishing:\nmalware samples forensic images packet captures raw lab screenshots with sensitive details full academic answers credential IDs transcripts private student data client information exact lab environment details raw exploit or crackme instructions sensitive infrastructure details Instead, I publish:\nwhat the work was about what tools or methods were used what the project shows what I learned why it matters for the roles I am targeting where the limits are That approach lets the site show real work without becoming a data leak.\nContent Strategy # The most important content decision was to stop treating every page as equally important.\nThe portfolio now has an evidence hierarchy.\nLevel Examples Purpose Flagship Evidence ServiceNow SecOps Lab Hub, CYBER 440 Capstone, CYBER 366 Malware Analytics, IST 454 Forensics, IST 456 Security \u0026 Risk Management. Lead With These Strong Supporting Evidence CYBER 342W, IST 432, IST 402, IST 331, CYBER 362, CYBER 262, IST 495. Support the Story Foundation Evidence SRA 221, SRA 231, SRA 311, IST 240, IST 242, IST 250, IST 261, IST 311. Show Progression This makes the site more honest. Not every course artifact should be a headline project. Some pages are there to show growth, foundation, and context.\nWhat Changed Over Time # The site started as a simpler portfolio. It became more structured as more evidence was added.\nMajor improvements included:\nGuided Review Flow # The site now has a clearer Start Here path and role-based review paths.\nNavigation\nMobile Cleanup # Cards, buttons, labels, and content blocks were adjusted so mobile pages feel less cramped and less broken.\nMobile\nBrand Cleanup # The default Blowfish favicon was replaced with the sudoRunner terminal-style favicon.\nBranding\nCredential Cleanup # Education, certifications, honor societies, and credentials were rebuilt into clearer static records.\nCredentials\nProject Expansion # Academic work was reviewed course by course, then converted into portfolio-safe case summaries.\nEvidence\nVoice Cleanup # The core pages were rewritten to sound more direct and less generic.\nWriting\nPages I Built or Reworked # Page Type Examples Why It Matters Core Reviewer Pages Start Here, Review Paths, Capabilities, Opportunity Fit Navigation Professional Pages Resume, About, Credentials, Contact Identity Evidence Pages Projects, Research \u0026 Labs, OT/ICS Security, AI \u0026 Security Proof of Work Site Maintenance Pages Portfolio Changelog, security metadata, contact routing, privacy-conscious public publishing choices. Product Thinking What This Project Shows # This project shows a mix of technical and communication skills:\nHugo static site development Blowfish customization Markdown content architecture custom CSS Git workflow Cloudflare Pages deployment custom DNS email routing responsive layout cleanup mobile usability testing HCI-focused navigation design security-conscious publishing technical writing content hierarchy project organization public professional branding The most important part is not that I can make a website.\nThe important part is that I can organize a large amount of technical evidence into something understandable, safe to publish, and usable by different audiences.\nWhat Was Harder Than Expected # A few things took more debugging than expected:\nfavicon replacement because browser and theme fallback caching were stubborn mobile layout collisions making buttons and labels visually distinct avoiding repeated content as more projects were added keeping course-coded project names consistent deciding what should be a flagship page versus supporting evidence writing about cybersecurity work without exposing too much detail making the site sound like a person wrote it, not a brochure Those were useful problems to solve because they are the same kind of problems that appear in real technical communication: structure, clarity, user flow, and safe disclosure.\nLimits # This site is not meant to be a raw evidence repository.\nIt does not prove every detail by publishing every file. That is intentional. A public cybersecurity portfolio should not expose everything.\nThe better goal is to show enough evidence for a reviewer to understand the work, then keep private materials available only for appropriate verification.\nNext Improvements # Things I may add later:\nprofessional headshot on the About page short Security Notes / Field Notes section better social preview metadata protected contact form with spam protection project-page “How to read this page” blocks for flagship projects cleaner diagrams for selected workflows accessibility audit more ServiceNow SecOps lab detail ServiceNow IRM/GRC learning path notes OT/ICS security reading notes Related Pages # Start Here Projects Capabilities Changelog ","date":"4 June 2026","externalUrl":null,"permalink":"/projects/sudorunner-portfolio-website/","section":"Projects","summary":"","title":"sudoRunner Portfolio Website","type":"projects"},{"content":"","date":"4 June 2026","externalUrl":null,"permalink":"/tags/technical-writing/","section":"Tags","summary":"","title":"Technical Writing","type":"tags"},{"content":"","date":"4 June 2026","externalUrl":null,"permalink":"/tags/triage/","section":"Tags","summary":"","title":"Triage","type":"tags"},{"content":" Using AI to Translate Vulnerability Risk Between Cybersecurity and OT Operations Teams # Content Type: Concept Note / AI SecOps Idea Lab\nThis article explores a professional concept for how AI could support cybersecurity, vulnerability management, and OT/ICS risk communication workflows. It is not presented as a completed production system or deployed enterprise implementation.\nVulnerability management often fails not because teams lack findings, but because findings are difficult to translate into action.\nIn traditional IT environments, a vulnerability may be prioritized based on severity, exploitability, asset criticality, exposure, and business impact. In OT and ICS environments, that conversation becomes more complex. A vulnerable system may support a physical process, production line, smart grid component, building automation function, or another operational process where availability and safety matter as much as confidentiality.\nThis creates a communication gap between cybersecurity teams and operations teams.\nSecurity teams may think in terms of CVEs, CVSS scores, vulnerable items, exploitability, remediation windows, and risk ratings. OT operations teams may think in terms of uptime, process stability, maintenance windows, vendor support, safety constraints, and operational continuity.\nAI could help bridge that gap.\nConcept # The idea is an AI-assisted workflow that translates vulnerability risk into language that different stakeholders can act on.\nInstead of simply showing an OT operations team a vulnerability record and expecting them to interpret the risk, an AI-assisted system could summarize the finding in operational terms.\nFor example, it could help answer:\nWhat is the vulnerability? Why does it matter? What system or process may be affected? Is the affected asset business-critical or operationally sensitive? Is there known exploit activity? Is immediate patching realistic? Are compensating controls available? What should the operations team do next? What should the cybersecurity team track? This would not replace analyst judgment. It would support analysts by improving the clarity, consistency, and usefulness of vulnerability communication.\nExample Workflow # A vulnerability is identified on an asset connected to an operational environment.\nA cybersecurity analyst reviews the vulnerable item, affected configuration item, severity, exploitability, known exposure, assignment group, and available remediation guidance.\nAn AI-assisted workflow could then generate a structured explanation for the OT operations team:\nTechnical summary A plain-language explanation of the vulnerability and affected system.\nOperational relevance Why this finding may matter to uptime, safety, maintenance, or process continuity.\nRisk translation A translation of cybersecurity severity into operational impact.\nRecommended next step Patch, validate vendor guidance, isolate, monitor, defer with exception, or apply compensating controls.\nEscalation guidance When to involve security leadership, system owners, engineering, or vendor support.\nAnalyst review checkpoint A required human review before any recommendation is sent or acted upon.\nWhy This Matters # OT and ICS environments often have constraints that traditional IT vulnerability management does not fully capture.\nA patch that is straightforward in IT may be disruptive in OT. A system may require vendor validation, downtime approval, maintenance window coordination, or safety review before remediation can occur.\nThat does not mean vulnerabilities should be ignored. It means the risk needs to be communicated in a way that supports better decisions.\nAI can help by creating consistent, role-specific summaries that reduce confusion between cybersecurity and operations teams.\nPossible ServiceNow SecOps Use Case # In a ServiceNow SecOps or Vulnerability Response workflow, this idea could be applied to vulnerable items, configuration items, assignment groups, remediation tasks, and exception handling.\nAn AI-assisted feature could review contextual information such as:\nVulnerable item details CVE information Risk rating Affected configuration item Asset owner or assignment group Business criticality Remediation history Exception history Known operational constraints Previous similar findings The output could be a recommended communication summary for the analyst to review before sending to the asset owner or operations team.\nThis would be especially useful when the cybersecurity team needs to explain why a finding matters beyond a generic severity score.\nHuman Oversight Is Required # AI should not be used as an automatic decision-maker in this workflow.\nThe analyst should remain responsible for reviewing the output, validating accuracy, confirming asset context, and ensuring that recommendations are appropriate.\nIn OT/ICS environments especially, incorrect or incomplete recommendations can create operational risk. AI should support better communication, not bypass engineering, safety, or operational review.\nPotential Benefits # This concept could help security teams:\nImprove communication between cybersecurity and OT operations Reduce misunderstanding around vulnerability severity Create more consistent risk explanations Support better remediation prioritization Improve exception documentation Help analysts explain findings to non-security stakeholders Connect vulnerability management to real operational impact Limitations # This idea would depend heavily on data quality.\nIf asset ownership, CMDB relationships, business criticality, exposure, or remediation history are inaccurate, the AI-generated explanation may also be inaccurate.\nThe system would need guardrails, human review, auditability, and clear boundaries around what AI can and cannot recommend.\nFinal Thought # The future of AI in cybersecurity should not only be about faster detection or automated response.\nOne of the most valuable uses may be helping security teams communicate risk more clearly.\nIn OT and ICS environments, that communication matters. A technically accurate finding is only useful if the right people understand what it means, why it matters, and what action should happen next.\nNote: This is a concept article and idea-lab writeup. It is intended to explore how AI could support cybersecurity and OT/ICS risk communication workflows. It is not presented as a completed production system.\n","date":"4 June 2026","externalUrl":null,"permalink":"/ai-security/using-ai-to-translate-vulnerability-risk/","section":"AI \u0026 Security","summary":"","title":"Using AI to Translate Vulnerability Risk Between Cybersecurity and OT Operations Teams","type":"ai-security"},{"content":"","date":"4 June 2026","externalUrl":null,"permalink":"/tags/vulnerability-management/","section":"Tags","summary":"","title":"Vulnerability Management","type":"tags"},{"content":"","date":"4 June 2026","externalUrl":null,"permalink":"/tags/vulnerability-response/","section":"Tags","summary":"","title":"Vulnerability Response","type":"tags"},{"content":"","date":"4 June 2026","externalUrl":null,"permalink":"/tags/web-design/","section":"Tags","summary":"","title":"Web Design","type":"tags"},{"content":"About sudoRunner\nsudoRunner is my professional cybersecurity portfolio.\nI built this site because a resume by itself does not show enough. A resume can list tools, courses, and projects, but it does not show how someone thinks through a workflow, writes about technical work, handles sensitive material, or organizes evidence for a reviewer.\nThis portfolio is meant to show that layer.\nPurpose: Show real evidence of my cybersecurity, ServiceNow SecOps, incident response, forensics, malware analysis, GRC, HCI, and application development work without publishing raw submissions, private data, malware samples, forensic evidence, credentials, or sensitive implementation details.\nWho I Am # I am a U.S. citizen and Penn State Cybersecurity Analytics \u0026amp; Operations graduate focused on ServiceNow SecOps, Vulnerability Response, cybersecurity operations, vulnerability management, and OT/ICS security.\nProfessionally, my strongest direction is ServiceNow SecOps and Vulnerability Response. I care about how security work actually moves: who owns the issue, what evidence supports the decision, how remediation is tracked, when exceptions make sense, how validation happens, and how the work gets closed cleanly.\nAcademically, my work spans incident response, malware analysis, reverse engineering, digital forensics, GRC, cloud security, network traffic analysis, user-centered design, Java application development, and security foundations.\nEducation # The Pennsylvania State University # B.S. Cybersecurity Analytics \u0026amp; Operations\nGraduated Cum Laude\nGPA: 3.88\nFocus Area: Application Development\nAcademic Honors: The Honor Society of Phi Kappa Phi · Alpha Sigma Lambda Honor Society\nCompleted Application Development Focus Phi Kappa Phi Alpha Sigma Lambda What I’m Building Toward # ServiceNow SecOps # This is the center of gravity for my career path. I want to keep building around Vulnerability Response, SecOps workflow, assignment ownership, remediation tracking, validation, and security process design.\nPrimary Focus\nSecurity Operations # I have hands-on academic evidence in malware analysis, forensics, network traffic analysis, SIEM-style investigation, incident response, and endpoint/security lab work.\nAnalyst Foundation\nGRC and Risk # I am interested in the bridge between technical evidence and risk decisions: policy, privacy, cyber law, decision theory, analytic confidence, and security management.\nRisk-Aware\nOT/ICS Security # OT/ICS security is a developing specialty interest. I am especially interested in cyber-physical risk, operational disruption, availability, safety, and recovery validation.\nSpecialty Interest\nHow to Read This Portfolio # This site is organized around evidence, not just categories.\nQuestion Best Place to Start Why What is my main professional direction? ServiceNow SecOps Lab Hub Primary Focus What is my strongest academic investigation project? CYBER 440 Capstone Flagship Evidence Where is malware analysis shown? CYBER 366 Malware Analytics Malware Where is digital forensics shown? IST 454 Computer \u0026 Cyber Forensics Forensics Where is GRC/risk shown? IST 456 Security \u0026 Risk Management Risk / GRC Where is professional experience shown? IST 495 Network Lab Development Internship Internship Work I Would Point to First # ServiceNow SecOps Lab Hub # The most career-aligned part of the site. It shows how I think about Vulnerability Response workflow, ownership, remediation, validation, exceptions, and closure.\nServiceNow SecOps Primary Focus CYBER 440: Cybersecurity Capstone Incident Response \u0026amp; Forensics # A capstone investigation where the value was connecting different evidence sources into one incident story: phishing, malware activity, forensic images, memory artifacts, logs, impact, and remediation.\nCapstone Incident Response CYBER 366: Malware Analytics \u0026amp; Reverse Engineering # The strongest malware-analysis lab collection in the portfolio. It includes static analysis, dynamic analysis, unpacking, FLOSS, ProcMon, RegShot, IDA Pro, Ghidra, Binary Ninja, and anti-debugging awareness.\nMalware Analysis Reverse Engineering IST 454: Computer \u0026amp; Cyber Forensics # Selected forensic evidence covering image creation, image mounting, hash verification, registry analysis, data carving, deleted file recovery, and AI/IoT forensics research.\nDigital Forensics Evidence Handling IST 456: Security \u0026amp; Risk Management # A useful bridge between SOC-style investigation and GRC: ransomware, compromised credentials, data exfiltration, ISO 27000 concepts, policy, compliance, and contingency planning.\nRisk Management GRC + SOC IST 331: User-Centered Design # The HCI evidence behind why I care about usability. It covers user research, low/high-fidelity prototypes, Figma collaboration, usability testing, and iterative redesign.\nHCI Usability What I Care About in Security Work # Clear Ownership # Security work breaks down when nobody owns the next step. I care about assignment, responsibility, escalation, and closure.\nOwnership\nEvidence Before Claims # I prefer showing evidence over listing buzzwords. A claim is stronger when it connects to a lab, project, workflow, or report.\nEvidence\nUsable Workflows # A workflow can be technically correct and still fail if people cannot follow it. HCI matters in security tools, dashboards, forms, and process design.\nHCI\nCareful Publishing # A lot of cybersecurity work should not be dumped publicly. I try to show what I learned without exposing raw evidence, full solutions, credentials, or sensitive details.\nSecurity First\nProfessional Direction # The roles I am most interested in are the ones that combine security workflows, technical analysis, risk thinking, and communication.\nBest-fit areas include:\nServiceNow SecOps consulting Vulnerability Response implementation support vulnerability management cybersecurity analyst work security operations incident response support GRC-aware security work OT/ICS security-focused roles Quick Links # Resume Projects Capabilities Review Paths Contact ","externalUrl":null,"permalink":"/about/","section":"","summary":"","title":"About","type":"page"},{"content":"","externalUrl":null,"permalink":"/authors/","section":"Authors","summary":"","title":"Authors","type":"authors"},{"content":"Portfolio Design System\nThis page explains the badge system used across sudoRunner.\nBadges are used to make project status, content type, professional focus, and portfolio relevance easier to scan.\nPurpose: The badge system helps visitors quickly understand whether a page is a hands-on lab, completed case study, concept note, specialty focus, or privacy-conscious portfolio item.\nBadge Types # Completed / Portfolio-Safe # Completed\nUsed for completed credentials, finished portfolio pages, stable project summaries, and finalized case-study content.\nIn Progress / Specialty Focus # In Progress\nUsed for active learning areas, specialty interests, planned improvements, or professional focus areas still being expanded.\nConcept / Idea Lab # Concept\nUsed for AI security ideas, future lab concepts, design ideas, and non-production research notes.\nHands-On Lab # Hands-On Lab\nUsed for lab-based work, practical exercises, technical investigations, and hands-on security or software projects.\nAcademic Honor # Cum Laude\nUsed for academic distinction and education-related highlights.\nHow Badges Are Used # Projects # Badges identify whether a project is ServiceNow-focused, cybersecurity-focused, academic, software engineering-related, OT/ICS-related, or web design-related.\nProject Context\nResearch \u0026amp; Labs # Badges separate hands-on lab work from conceptual notes, future lab ideas, and active focus areas.\nLab Context\nCredentials # Badges show completed credentials, scheduled exams, academic achievements, and credential progress.\nCredential Status\nCapabilities # Badges help connect professional capabilities to evidence across projects, labs, and portfolio pages.\nSkill Mapping\nRelated Pages # Projects Capabilities Changelog ","externalUrl":null,"permalink":"/badge-legend/","section":"","summary":"","title":"Badge Legend","type":"page"},{"content":"Capability-to-Evidence Map\nThis page connects what I claim to actual work in the portfolio.\nIt is not meant to list every tool I have ever touched. It is meant to answer a simpler question:\nWhat can I credibly talk about in an interview, and where is the evidence?\nStrongest Capability Areas # Capability Evidence Best Fit ServiceNow SecOps / Vulnerability Response My most career-aligned work. The ServiceNow SecOps Lab Hub focuses on vulnerable item triage, ownership, remediation tracking, validation, exceptions, and closure. The VR Triage Checklist shows how I think through the workflow. Primary Focus Incident Response and Investigation CYBER 440 is the strongest investigation page: phishing, malware activity, forensic images, memory artifacts, logs, impact, and remediation. CYBER 342W adds the planning side: NIST 800-61, CSIRT, communication, DR/BC, and lessons learned. IR Digital Forensics IST 454 covers forensic imaging, mounting, hash verification, registry analysis, data carving, deleted file recovery, and AI/IoT forensics research. CYBER 440 shows how forensic evidence fits into a broader incident story. Forensics Malware Analysis and Reverse Engineering CYBER 366 covers static analysis, dynamic analysis, UPX unpacking, FLOSS, PEiD, ProcMon, RegShot, IDA Pro, Ghidra, Binary Ninja, anti-debugging, and keylogging indicators. IST 451 Malware-Based Attack Investigation adds a defensive investigation angle. Malware Security Operations and SIEM Thinking IST 456 shows Enigma Glass SIEM-style investigation around ransomware, compromised credentials, and data exfiltration. SRA 221, CYBER 262, and CYBER 362 add Splunk, Wireshark, IDS/SIEM, packet analysis, and anomaly detection foundations. SOC-Relevant GRC, Risk, Privacy, and Decision-Making IST 456 covers risk management and policy. IST 432 adds cyber law and privacy. SRA 311 adds source credibility, analytic confidence, risk treatment, and threat modeling. SRA 231 is the decision-theory foundation underneath that work. GRC Cloud Security and Emerging Technology IST 402 covers Hyper-V, OpenStack, Docker, Docker Compose, secure cloud architecture, mTLS, zero trust concepts, shared responsibility, Wazuh/OpenSCAP exposure, and SECaaS strategy. Cloud OT/ICS Security My OT/ICS interest is represented by the OT/ICS Security section and the IST 451 ICS/IT-OT Application-Level DoS Attack Lab. The focus is cyber-physical risk, SCADA/PLC concepts, availability, operational impact, and recovery validation. Specialty Interest Supporting Technical Foundations # Application Development # The software path is strongest when read as progression: IST 240 → IST 242 → IST 261 → IST 311.\nThis covers Java, OOP, inheritance, interfaces, GUI work, MVC, persistence, task queues, testing, data structures, Big-O, and Git workflow.\nSoftware Foundation\nHCI and Workflow Design # IST 331 is the academic evidence behind my usability focus. It covers user research, prototypes, Figma collaboration, usability testing, and iterative redesign.\nThis also connects directly to how I have been shaping this portfolio.\nHCI\nNetworking and Technical Documentation # IST 495 is professional experience with Penn State College of IST. It involved networking lab modernization, technical research, lab validation, documentation, rubrics, teamwork, and supervisor updates.\nInternship\nWeb and Portfolio Engineering # IST 250 shows early web design work. The sudoRunner Portfolio Website shows the live version of that skill: Hugo, Cloudflare Pages, DNS, custom CSS, mobile fixes, favicon branding, and guided review paths.\nWeb\nAI-Assisted SecOps Ideas # The AI-Powered Vulnerability Ownership Recommender is not a production system. It is a concept for how AI could support analyst-reviewed assignment routing and remediation decision support in ServiceNow SecOps.\nConcept\nSecurity Foundations # SRA 221, CYBER 262, and IST 451 show the earlier hands-on foundation behind the larger incident response, malware, forensics, and GRC pages.\nFoundation\nTools and Platforms I Can Discuss # This is not a claim of expert-level mastery in every tool. It is a practical map of tools I have used in coursework, labs, projects, or portfolio work.\nArea Tools / Platforms Evidence ServiceNow / SecOps ServiceNow SecOps, Vulnerability Response concepts, vulnerable item workflow, assignment ownership, remediation, validation, closure, requirements, UAT, and process documentation. Primary Forensics / IR FTK Imager, WinHex, RegRipper, Registry Viewer, forensic imaging, memory artifacts, Windows logs, event timelines, and evidence handling concepts. Hands-On Malware / Reverse Engineering PEiD, UPX, FLOSS, strings, ProcMon, Process Explorer, RegShot, IDA Pro, Ghidra, Binary Ninja, Windows API interpretation, and debugger-aware behavior. Hands-On Security Operations Splunk, Enigma Glass, Wireshark, Snort, Wazuh, OWASP ZAP, SPARTA, OpenVPN, pfSense, Active Directory, and SIEM-style investigation workflows. Foundational Cloud / Infrastructure Hyper-V, OpenStack, Docker, Docker Compose, Wazuh, OpenSCAP, mutual TLS concepts, zero trust concepts, and shared responsibility. Cloud Software / Web Java, OOP, MVC, JUnit-style testing, Git, HTML, CSS, JavaScript, Hugo, Blowfish, GitHub, Cloudflare Pages, DNS, and custom CSS. Development HCI / Design Figma, user research, low-fidelity prototypes, high-fidelity prototypes, usability testing, workflow modeling, and mobile usability review. HCI How I Think About the Work # I prefer evidence over claims. # A resume can say “incident response” or “risk analysis.” The portfolio is meant to show where those claims come from.\nEvidence\nI care about workflow, not just tools. # Most of the stronger projects are about connecting steps: triage, ownership, investigation, validation, reporting, and closure.\nWorkflow\nI publish carefully. # A lot of the work involves malware, forensics, security labs, academic material, or simulated environments. I summarize the learning without exposing raw evidence or full solutions.\nSecurity First\nRecommended Review Paths # ServiceNow / Vulnerability Response # Start with the ServiceNow SecOps Lab Hub, then review IST 456 and the AI ownership recommender.\nSecOps Path\nCybersecurity Analyst # Start with CYBER 440, CYBER 366, IST 454, CYBER 362, CYBER 262, and IST 456.\nAnalyst Path\nGRC / Risk # Start with IST 456, IST 432, SRA 311, SRA 231, and CYBER 342W.\nRisk Path\nView Projects Review Paths Resume Contact ","externalUrl":null,"permalink":"/capabilities/","section":"","summary":"","title":"Capabilities","type":"page"},{"content":" Professional Contact\nThis page provides professional contact options for relevant opportunities, technical conversations, and portfolio review follow-up.\nBest fit opportunities: ServiceNow SecOps, Vulnerability Response, cybersecurity analyst work, vulnerability management, security operations, consulting, and OT/ICS security-focused roles.\nContact Options # Email # For professional opportunities, portfolio review, or relevant technical conversations, contact me at:\ncontact@sudorunner.org\nProfessional Alias Public Contact LinkedIn # Use LinkedIn for professional networking, recruiter outreach, and opportunity-related messages.\nView LinkedIn Profile\nProfessional Network Recruiter Friendly Intro Call # For role-relevant conversations, the best starting point is a short introduction call after reviewing the portfolio and resume.\nRequest an Intro Call\nAvailable by Request Scheduling Link Pending Before Reaching Out # Recommended Review Path # Start with the guided portfolio path before reaching out:\nStart Here → Resume → ServiceNow SecOps → Projects\nReviewer Friendly\nOpportunity Fit # The portfolio is most aligned with ServiceNow SecOps, Vulnerability Response, cybersecurity analyst, vulnerability management, security operations, consulting, and OT/ICS security-focused opportunities.\nRole Alignment\nSecurity and Privacy # This site uses a public-facing contact alias and intentionally avoids publishing private contact details, raw academic submissions, credentials, sensitive screenshots, client data, or confidential implementation details.\nSecurity First\nQuick Links # Resume Opportunity Fit Projects ","externalUrl":null,"permalink":"/contact/","section":"Contact","summary":"","title":"Contact","type":"contact"},{"content":"Credentials\nThis page is the public summary of my education, certifications, academic honors, and professional development.\nI keep the sensitive parts private. Credential IDs, transcripts, raw academic submissions, certificates with private metadata, and verification documents are not published here.\nHow to read this page: The credentials show the formal background. The project pages show the work behind it.\nEducation # The Pennsylvania State University # B.S. Cybersecurity Analytics \u0026amp; Operations\nGraduated Cum Laude\nGPA: 3.88\nFocus Area: Application Development\nAcademic Honors: The Honor Society of Phi Kappa Phi · Alpha Sigma Lambda Honor Society\nRelevant areas of study included cybersecurity operations, network security, risk analysis, application development, incident response concepts, malware analysis foundations, digital forensics, user-centered design, and security-focused technical foundations.\nCompleted Application Development Focus Phi Kappa Phi Alpha Sigma Lambda Certifications # Credential Code / Detail Status ServiceNow Certified System Administrator CSA · scheduled June 2026 Scheduled ISC2 Certified in Cybersecurity CC Completed Microsoft Azure Fundamentals AZ-900 Completed Microsoft Security, Compliance, and Identity Fundamentals SC-900 Completed Penn State Certificates and Academic Recognition # Recognition Detail Status Penn State Security and Risk Analysis Certificate SRA Completed Penn State National Security Agency Certificate NSA Completed Graduated Cum Laude Penn State University · B.S. Cybersecurity Analytics \u0026 Operations · GPA 3.88 Completed The Honor Society of Phi Kappa Phi Academic honor society membership Member Alpha Sigma Lambda Honor Society Academic honor society membership Member SANS NetWars CTF 14th nationwide placement Completed Professional Development # Training Why it matters Status Diversity, Inclusion, and Belonging Professional development training. I would not treat this as a technical credential, but it belongs here as a completed workplace-readiness item. Completed Evidence Behind the Credentials # These are the pages that best show the work behind the formal background.\nServiceNow SecOps Lab Hub # Best evidence for my ServiceNow SecOps and Vulnerability Response direction.\nServiceNow SecOps Primary Focus CYBER 440: Cybersecurity Capstone Incident Response \u0026amp; Forensics # Best evidence for incident response, forensic investigation, timeline development, impact assessment, and remediation planning.\nCapstone Incident Response CYBER 366: Malware Analytics \u0026amp; Reverse Engineering # Best evidence for malware analysis, reverse-engineering workflow, static/dynamic analysis, and tool exposure.\nMalware Analysis Reverse Engineering IST 454: Computer \u0026amp; Cyber Forensics # Best evidence for forensic imaging, hash verification, registry analysis, data carving, and deleted file recovery.\nDigital Forensics Evidence Handling IST 456: Security \u0026amp; Risk Management # Best evidence for security risk management, SIEM-style investigation, ransomware response, compromised credentials, data exfiltration, policy, and GRC thinking.\nRisk Management GRC + SOC IST 495: Network Lab Development Internship # Best evidence for professional internship experience, networking lab modernization, technical documentation, QA testing, and supervisor-facing communication.\nInternship Networking Course-Coded Academic Evidence # Course / Experience Evidence Area IST 495 Penn State College of IST Network Lab Development Internship Internship CYBER 440 Cybersecurity Capstone Incident Response \u0026 Forensics Capstone CYBER 366 Malware Analytics \u0026 Reverse Engineering Lab Collection Malware IST 454 Computer \u0026 Cyber Forensics Lab Evidence Forensics IST 456 Security \u0026 Risk Management with Enigma Glass Labs Risk / GRC CYBER 342W Incident Response, Disaster Recovery \u0026 Business Continuity Planning IR Planning IST 432 Cyber Law, Privacy \u0026 GRC Case Analysis Cyber Law SRA 311 Risk Analysis in a Security Context Risk Analysis IST 331 User-Centered Design \u0026 Booking.com Redesign HCI IST 402 Cloud Virtualization, Containers \u0026 SECaaS Architecture Cloud IST 261 Productivity Assistant Application Design Studio Application Development Private Verification # I keep verification material private unless a recruiter, employer, or authorized reviewer needs it.\nI do not publish:\ncertification IDs transcripts student records raw certificates with private metadata full academic submissions screenshots containing sensitive course/lab information private contact details That keeps the public portfolio useful without turning it into a document dump.\nQuick Links # Resume Projects Capabilities Contact ","externalUrl":null,"permalink":"/credentials/","section":"Credentials","summary":"","title":"Credentials","type":"credentials"},{"content":" Course Impact # This course was a turning point in my cybersecurity development because it pushed me toward hands-on work beyond normal assignments, including CTF participation, independent research, and deeper systems-level learning.\nIt helped reinforce an important lesson: cybersecurity is not only about completing labs. It is about staying curious, practicing outside the minimum requirements, and developing the discipline to understand how systems actually behave.\nLab Areas Covered # Linux + Log Analysis # Command-line parsing, grep, awk, sort, uniq, log filtering, and evidence formatting.\nLinux\nHost-Based Defense # Firewall policy, UFW default deny, allowed services, scanning exposure, and drop-vs-reject reasoning.\nDefense\nEndpoint Protection # Microsoft System Center concepts, antimalware policies, endpoint alerts, deployments, updates, and reference imaging.\nEndpoint Security\nHIDS + NIDS # Wazuh HIDS, Snort NIDS, rootcheck, filesystem monitoring, SSH brute-force detection, rule validation, and alert review.\nDetection\nPython + strace Parsing # Python scripting to parse system-call logs, identify executed programs, count events, and extract process identifiers.\nPython\n2FA + Memory Safety # TOTP concepts, replay resistance, time skew, rate limiting, Set-UID behavior, NOP sleds, EBP, and buffer overflow fundamentals.\nSecurity Concepts\nWork Included # Practice Lab Environment # The first lab involved accessing and navigating the Practice Labs environment.\nThis was a basic setup lab, but it still matters because much of cybersecurity learning depends on being able to work inside lab infrastructure, troubleshoot access issues, and continue despite environment problems.\nPortfolio value:\nlab environment setup troubleshooting practice endpoint protection exposure early hands-on workflow discipline This lab is supporting material only and is not strong enough to publish as a standalone project.\nHost-Based Network Defense # This lab focused on host-based network defense, scanning, weak service exposure, and firewall policy.\nThe work included:\nadding a user account to a system scanning from Kali using Zenmap password discovery using Ncrack testing telnet access applying UFW default deny behavior configuring allowed access validating which ports remained reachable comparing drop and reject behavior The strongest portfolio value is the defensive reasoning: understanding that exposed services, weak credentials, and permissive firewall behavior create risk, and that firewall policy should be intentional rather than assumed.\nKey lesson:\nA host-based firewall is not only a configuration checkbox. It directly controls which services are exposed, which connections are allowed, and how much information a system reveals to a scanner or attacker.\nEndpoint Protection and Enterprise Controls # This lab focused on Microsoft System Center and endpoint protection tasks.\nThe work included:\nadding an Endpoint Protection site system role configuring endpoint protection alerts configuring definition updates reviewing automatic deployment rules creating and deploying antimalware policies reviewing compliance settings configuring custom client settings verifying endpoint protection installation discussing the value of reference computers and imaging The strongest portfolio value is enterprise endpoint management thinking.\nKey lesson:\nEndpoint protection is not only antivirus. In an enterprise setting, it involves policy, deployment, update cadence, monitoring, compliance, alerting, and recoverability.\nWazuh HIDS Detection # This lab focused on host-based intrusion detection using Wazuh.\nThe work included:\ndetecting SSH brute-force attempts reviewing detailed log evidence understanding Wazuh agent behavior file integrity monitoring concepts process and anomaly checks rootkit/rootcheck behavior hidden process detection filesystem change detection Kibana dashboard review monitoring privilege escalation behavior such as sudo su The strongest portfolio value is detection and investigation workflow.\nKey lesson:\nA host-based intrusion detection system is useful because it connects endpoint activity, file integrity, process behavior, rootkit indicators, and log visibility into analyst-reviewable evidence.\nSnort NIDS and Security Onion # This lab focused on Snort network intrusion detection.\nThe work included:\nvalidating Snort configuration reviewing local detection rules understanding rule chains discussing white_list.rules and black_list.rules identifying Security Onion rule directory placement validating rules with snort -T applying rule updates searching alerts with command-line tools reviewing alerts in Kibana discussing filtering with Snort and downstream monitoring explaining why a Snort sensor may be deployed in a DMZ interpreting example Snort rules and alert messages The strongest portfolio value is network detection engineering fundamentals.\nKey lesson:\nNIDS work requires more than seeing alerts. Analysts must understand where rules live, how rules are validated, how alerts map to traffic behavior, where sensors should be placed, and how to investigate alerts efficiently.\nMetasploit and Penetration Testing Exposure # This lab introduced Metasploit and penetration-testing workflow concepts.\nThe available document is mostly screenshot placeholders, so I would treat it as supporting evidence only rather than a standalone portfolio item.\nPortfolio value:\nexposure to penetration-testing tooling offensive-security workflow awareness lab-based attacker/defender context This should not be over-emphasized publicly because the available written evidence is limited.\nLinux Log Analysis # The log analysis homework focused on Linux parsing and command-line analysis.\nThe work included:\nfinding attempts to run sudo counting attempts by a specific user using grep using wc formatting output with awk sorting output summarizing occurrences with uniq -c preparing findings for downstream review The strongest portfolio value is practical analyst workflow.\nKey lesson:\nCommand-line parsing is a core analyst skill because it allows fast filtering, counting, formatting, and summarizing of raw evidence before it is moved into reports or other tools.\nPython-Based strace Parsing # This work used Python to parse Linux strace output.\nThe code and output show practice with:\nreading log files scanning for system-call patterns counting events identifying execve identifying write identifying fstat, stat, and access extracting program names extracting process IDs building helper functions printing structured analysis output This was an important bridge between programming and cybersecurity analysis.\nKey lesson:\nPython can help turn noisy system-call traces into structured evidence. Even simple parsing logic can help identify program execution, process behavior, file access patterns, and suspicious activity indicators.\nSplunk Fundamentals # This lab introduced Splunk fundamentals.\nThe available document is mostly structured around topic areas such as:\nwhat Splunk is intro to Splunk using fields scheduling reports and alerts visualizations search under the hood The written detail is limited, so this should be treated as supporting evidence rather than a major standalone case study.\nPortfolio value:\nSIEM exposure search and field concepts alerting/reporting awareness visualization awareness Two-Factor Authentication # This lab focused on two-factor authentication concepts.\nThe work included:\nsetting up a 2FA challenge-response flow discussing secret keys explaining time skew explaining rate limiting using Google Authenticator validating SSH access explaining how time-based, single-use tokens reduce replay risk The strongest portfolio value is authentication security reasoning.\nKey lesson:\n2FA security depends on implementation details. Time skew, rate limiting, single-use tokens, and time-based token validity all affect how resistant an authentication flow is to replay and brute-force attempts.\nBuffer Overflow Concepts # This lab introduced buffer overflow behavior and low-level exploitation concepts.\nThe work included:\nSet-UID file permission review running a vulnerable C program observing segmentation faults testing input length behavior working with badfile reviewing GDB values analyzing hexdump output identifying NOP behavior discussing EBP explaining what happens when execution returns to a controlled address The lab did not fully complete privilege escalation due to segmentation-fault behavior, so this portfolio page does not claim a successful exploit chain. The value is in the systems-level learning: stack behavior, memory layout, payload structure, debugging, and why memory safety matters.\nKey lesson:\nBuffer overflow concepts reveal how a program can behave differently from what a user sees on screen. Understanding stack behavior, return addresses, NOPs, and memory layout helps explain why memory safety is critical and how malicious code can execute without obvious user awareness.\nSkills Demonstrated # This lab collection demonstrates:\nLinux command-line analysis log parsing and evidence formatting Python scripting for security analysis host-based firewall reasoning endpoint protection concepts Microsoft System Center exposure Wazuh HIDS concepts Snort NIDS concepts Security Onion exposure Kibana alert review Splunk fundamentals SSH brute-force detection filesystem change detection rootkit/rootcheck concepts 2FA and TOTP reasoning replay-attack prevention concepts buffer overflow fundamentals GDB/hexdump exposure Set-UID and privilege concept awareness defensive and offensive security context Security Operations Relevance # This collection is relevant to security operations because it shows multiple layers of security work:\nprevention through firewall policy and endpoint controls detection through HIDS/NIDS tools investigation through logs, Kibana, Splunk, and command-line parsing authentication hardening through 2FA systems-level understanding through buffer overflow labs automation support through Python parsing Together, these labs helped build the foundation for later work in vulnerability management, ServiceNow SecOps, incident response, network traffic analysis, malware investigation, and OT/ICS security.\nWhat I Would Improve Today # If I revisited this work today, I would improve it by:\nwriting cleaner executive summaries for each lab separating screenshots from analysis more clearly documenting exact investigation questions before each task improving Python code structure and error handling adding comments that explain why each parsing step matters avoiding overly broad claims where lab evidence is limited connecting each lab more directly to SOC workflows adding diagrams for HIDS/NIDS detection flow adding sanitized examples of alert triage notes improving final recommendations for each defensive control Portfolio Note # This page is a sanitized academic case study.\nRaw screenshots, full lab submissions, secret keys, exploit payloads, exact lab answers, personal identifiers, and complete solution files are not published. The purpose is to demonstrate cybersecurity foundations, analyst thinking, and practical lab exposure without turning the portfolio into a homework archive.\n","externalUrl":null,"permalink":"/research-labs/cyber-262-security-foundations-lab-collection/","section":"Research \u0026 Labs","summary":"","title":"CYBER 262: Security Foundations Lab Collection","type":"research-labs"},{"content":"Redacted Academic Case Study\nThis case study summarizes a Penn State cybersecurity project involving packet-level investigation, suspicious file analysis, supervised machine learning, clustering, Splunk-based analysis, and security recommendations.\nType Academic Cybersecurity Project Focus Network Traffic Analysis Methods Packet Review · ML Classification · Clustering Tools Wireshark · Security Onion · Splunk · Python Outcome Anomaly Detection + Security Recommendations Privacy Level Redacted / No Raw Submission Published Content Type: Redacted Academic Project / Cybersecurity Case Study\nThis case study is based on academic coursework completed at Penn State. It has been rewritten and sanitized for portfolio use. It does not include teammate names, professor names, student emails, raw screenshots, full submitted files, or unnecessary identifying details.\nOverview # This project focused on analyzing network traffic to distinguish normal activity from potentially suspicious or malicious behavior.\nThe work combined packet-level investigation, traffic analysis, supervised machine learning, clustering, and security recommendations. The goal was to evaluate network activity, identify suspicious patterns, compare classification approaches, and communicate findings in a way that could support security operations decision-making.\nProject Context # The project scenario involved a fictional organization reviewing network traffic collected over a multi-day period. The dataset contained a mix of legitimate traffic and potentially suspicious activity.\nThe main challenge was that not all data was clearly labeled, which reflects a realistic security operations problem: analysts often need to investigate large volumes of network activity without perfect ground truth.\nTools and Technologies # Tools and concepts used included:\nWireshark Security Onion Splunk Python scikit-learn pandas supervised machine learning clustering traffic classification anomaly detection confusion matrices precision, recall, accuracy, and F1 score My Role # For this project, I contributed to the analysis, machine learning experimentation, interpretation of results, and security recommendations.\nThe project required both technical analysis and written communication. The final output needed to explain what was observed, what methods were used, which results were meaningful, and what actions could improve the organization’s security posture.\nAnalysis Performed # Packet and Traffic Investigation # The project included investigation of suspicious network traffic using packet analysis tools.\nOne notable finding involved a large executable download from an unfamiliar hostname. This traffic was reviewed as potentially suspicious because executable downloads from unexpected or advertisement-related sources can create malware risk.\nThe analysis considered:\nsource and destination details packet-level context TCP stream behavior file type concerns suspicious hostname context possible malware delivery risk Supervised Machine Learning # The project also used supervised machine learning to classify labeled network flow data as normal or attack traffic.\nSeveral classification models were evaluated:\nLogistic Regression Decision Tree Random Forest Multi-Layer Perceptron The workflow included:\nloading labeled network flow data removing irrelevant fields encoding categorical variables selecting useful traffic features scaling feature values splitting training and testing data fitting classification models comparing model performance Performance was evaluated using:\nconfusion matrix accuracy precision recall F1 score Clustering and Anomaly Detection # The project also explored clustering approaches for identifying unusual traffic behavior.\nThe clustering analysis included:\nK-Means DBSCAN traffic length observations outlier review comparison between dense clusters and less structured traffic groupings This helped demonstrate how unsupervised methods can support anomaly detection when labeled data is incomplete or unavailable.\nKey Findings # The project highlighted several important cybersecurity lessons.\nFirst, suspicious network activity may require multiple forms of analysis. A packet capture alone may show technical evidence, but the analyst still needs context to determine whether the activity is truly malicious, suspicious, or benign.\nSecond, supervised machine learning can help classify large volumes of network flow data, but model results must be interpreted carefully. Accuracy alone is not enough. Precision, recall, F1 score, confusion matrices, and false negatives matter when evaluating detection usefulness.\nThird, clustering can help identify unusual traffic patterns, but not every cluster or outlier automatically represents malicious behavior. Analyst judgment is still required.\nFourth, security recommendations should connect technical findings to operational improvements such as better monitoring, employee training, patching, IDS/IPS, SIEM visibility, and incident response readiness.\nSecurity Recommendations # Based on the analysis, the project recommended improvements such as:\nstrengthening intrusion detection and intrusion prevention capabilities using SIEM tools for centralized visibility and alerting improving employee awareness around suspicious downloads and phishing risk maintaining regular patching and firmware updates disabling unnecessary services enforcing multi-factor authentication where appropriate performing log review, audits, and recurring security assessments using machine learning as a supporting tool for large-scale detection and triage What This Project Demonstrates # This project demonstrates hands-on academic experience with:\nnetwork traffic analysis packet investigation suspicious file review cybersecurity data analysis supervised machine learning anomaly detection concepts Splunk-based security analysis comparing model performance translating findings into security recommendations Lessons Learned # The most important lesson from this project is that cybersecurity analysis requires both technical evidence and context.\nMachine learning can help identify patterns at scale, but it should not replace analyst review. Packet captures, flow data, model outputs, and SIEM results all need to be interpreted together.\nThe project also reinforced the importance of communicating findings clearly. A technically interesting result only becomes useful when it leads to better detection, prioritization, response, or risk reduction.\nWhat I Would Improve # If I expanded this project today, I would improve it by:\ndocumenting the feature engineering process more clearly separating model performance by attack and normal traffic classes focusing more on false negatives and detection impact adding clearer visualizations of model comparison creating a cleaned lab version of the dataset workflow mapping findings to MITRE ATT\u0026amp;CK or security operations use cases building a short detection-and-response playbook from the suspicious traffic finding Portfolio Note # This page is a sanitized case study. The original academic files are not published because they contain course metadata, group details, screenshots, and raw project formatting that are not necessary for employer review.\nThe purpose of this writeup is to show the project’s technical scope, methods used, and cybersecurity lessons learned without exposing full submissions or unnecessary identifying information.\n","externalUrl":null,"permalink":"/projects/network-traffic-analysis-ml-anomaly-detection/","section":"Projects","summary":"","title":"CYBER 362: Network Traffic Analysis \u0026 ML-Based Anomaly Detection","type":"projects"},{"content":" Why This Work Matters # Malware analysis is not only about identifying that a file is malicious. A useful analyst needs to understand what evidence supports that conclusion.\nThis course helped build a repeatable workflow for asking practical questions:\nWhat kind of file is this? Is the file packed or obfuscated? What strings or imports are visible? Does the executable make changes to the registry or file system? Does it attempt network activity? Does it create processes or launch other applications? Does it behave differently under a debugger? What artifacts could help identify similar behavior later? What information is safe to report publicly? Those questions are directly relevant to cybersecurity analyst work, malware triage, detection engineering, incident response, endpoint investigation, and security operations.\nPortfolio-Safe Publishing Approach # Security note: This page summarizes academic malware-analysis work without publishing raw malware samples, exact exploit steps, full crackme solutions, sensitive screenshots, private academic files, or operational instructions that could be misused.\nThe goal is to show technical depth without exposing:\nmalware binaries raw executable hashes exact compromised infrastructure details complete patching or bypass walkthroughs full crackme solutions private screenshots private academic submissions instructor-provided files lab environment details that should remain private Instead, the work is presented as:\nsanitized workflows tool usage summaries analysis categories behavioral observations lessons learned skill evidence portfolio-safe technical outcomes Analysis Workflow # 1 Initial Triage # Reviewed file types, hashes, content types, host artifacts, and basic indicators to understand what suspicious files were present and what systems or hosts were involved.\nTriage\n2 Static Analysis # Used tools such as strings, PEiD, VirusTotal, UPX, and FLOSS to review readable strings, packed executable behavior, file metadata, compiler hints, imported functions, and decoded strings.\nStatic Analysis\n3 Dynamic Analysis # Observed behavior in a controlled lab environment using tools such as Process Explorer, Process Monitor, and RegShot to identify process behavior, registry modifications, file writes, and network activity.\nDynamic Analysis\n4 Reverse Engineering # Used IDA Pro, Ghidra, and Binary Ninja concepts to locate main functions, interpret strings, review imports, follow control flow, and reason about malware behavior at a lower level.\nReverse Engineering\n5 Behavioral Interpretation # Mapped observed technical evidence to practical behavior such as persistence attempts, registry modification, file creation, process spawning, debugger-aware logic, keylogging indicators, and user-impacting actions.\nBehavior Mapping\n6 Reporting # Converted technical findings into concise analysis summaries, focusing on what was observed, what it suggested, and what could be used as safe detection or investigation context.\nReporting\nLab Collection Summary # Malware Triage and Indicators # Early work focused on identifying downloaded file types, reviewing unique hashes, identifying potentially malicious files, and connecting host artifacts to a suspicious web event.\nInitial Triage\nPacked Executable Review # Static analysis work included identifying a packed executable, unpacking it in a controlled lab context, comparing visible strings before and after unpacking, and reviewing how unpacking changed the analysis surface.\nUPX + PEiD\nStrings and FLOSS Analysis # The labs used readable strings, decoded strings, and stack-string extraction to identify meaningful clues that were not obvious from a basic file review.\nString Analysis\nPreliminary Dynamic Analysis # Dynamic-analysis work included process review, registry monitoring, file-write observation, and comparison of system state before and after execution in a controlled environment.\nProcMon + RegShot\nDisassembly and Control Flow # Later labs used IDA Pro and Ghidra to locate main functions, inspect strings, interpret branching behavior, review imported functions, and connect code-level observations to executable behavior.\nIDA + Ghidra\nAnti-Debugging Awareness # In this lab I worked on areas such as debugger-aware behavior, including analysis of a program path that changed when debugger detection logic was present.\nAnti-Debugging\nKeylogging Indicators # One advanced static-analysis lab involved identifying suspicious hook-related behavior and reasoning about how the executable could capture user input or persist in a system context.\nKeylogging Indicators\nBinary Analysis Tooling # A team project explored Binary Ninja as a reverse-engineering and binary-analysis platform, including system requirements, installation flow, user interface concepts, disassembly/decompilation features, debugger support, and plugin/API capabilities.\nBinary Ninja\nTools and Techniques Used # Area Tools / Concepts File triage File type review, hash comparison, suspicious file grouping Reputation review VirusTotal-style detection review and threat-label interpretation PE inspection PEiD, entry point review, subsystem review, section review Unpacking UPX identification and unpacking in a lab context String analysis strings, FLOSS, decoded strings, stack-string review Dynamic analysis Process Explorer, Process Monitor, RegShot, clean snapshot comparison Reverse engineering IDA Pro, Ghidra, Binary Ninja concepts Windows behavior registry activity, file writes, process creation, imported API review Debugging awareness debugger detection logic and alternate execution paths Reporting portfolio-safe behavioral summary and analysis conclusions Technical Themes # Static Analysis # Static analysis helped identify what could be learned without running the executable.\nThis included reviewing:\nreadable strings imported libraries PE metadata entry points packed versus unpacked state visible and decoded strings likely behavioral clues compiler and subsystem information The important lesson was that static analysis often gives direction, but not complete proof. It can suggest behavior, but dynamic analysis or deeper reverse engineering may be needed to confirm what the program actually does.\nDynamic Analysis # Dynamic analysis helped connect executable behavior to real system changes.\nThe labs included controlled observation of:\nprocess behavior registry modification file creation and file writes lack of observed network traffic in some samples before-and-after system state comparison user-impacting executable behavior This reinforced the difference between what a file appears capable of doing and what it actually does when executed in a monitored environment.\nReverse Engineering # IDA Pro and Ghidra were used to reason about executable behavior at a lower level.\nThe work included:\nlocating main functions following control flow searching for meaningful strings reviewing imported APIs interpreting conditional logic connecting disassembly/decompiler output to real behavior comparing findings across tools This was one of the strongest parts of the course because it connected malware behavior to the underlying program structure.\nAnti-Debugging and Analyst Friction # One lab introduced debugger-aware behavior.\nThe key lesson was that malware analysis can be affected by whether the sample detects analysis tooling. Debugger-aware logic can change execution paths, throw exceptions, terminate behavior, or mislead an analyst.\nFrom a portfolio standpoint, this is useful because it shows awareness that malware analysis is adversarial. The sample is not always passive; it may behave differently when it detects observation.\nKeylogging and User-Input Risk # One advanced lab involved suspicious input-capture behavior.\nThe analysis focused on hook-related indicators, persistence-related behavior, and how a malicious executable could capture keystrokes or monitor user activity.\nThe portfolio-safe lesson is that keylogger analysis requires connecting multiple signals:\nimported Windows APIs hook-related strings process behavior persistence indicators file or registry artifacts analyst interpretation of program purpose Binary Ninja Tool Research # The course also included a team project on Binary Ninja.\nThe project covered Binary Ninja as a multi-function binary-analysis platform with capabilities such as:\ndisassembly decompilation debugging graph-based code navigation cross-reference review intermediate language views plugin support API-driven automation patching and binary triage features My portion of the project focused on installation and system requirements, including supported operating systems, resource requirements, download/setup considerations, and opening files for analysis.\nCapability-to-Evidence Map # Capability Evidence Status Malware Triage File type review, suspicious file grouping, hash comparison, host/infrastructure context. Completed Static Analysis Strings, PEiD, packed executable review, UPX unpacking, FLOSS output, PE metadata. Completed Dynamic Analysis Process Explorer, ProcMon, RegShot, registry/file-system behavior, clean-state comparison. Completed Reverse Engineering IDA Pro, Ghidra, main-function location, string references, imported API interpretation, control-flow reasoning. Completed Anti-Debugging Awareness Debugger-detection logic, branch behavior, exception path reasoning, analyst-friction awareness. Completed Binary Analysis Tooling Binary Ninja research, installation/system requirements, feature review, disassembly/decompilation workflow concepts. Completed What I Learned # This course strengthened my understanding of how malware analysis is built from layers of evidence.\nThe biggest lessons were:\nstatic analysis gives clues, not always certainty packed executables can hide important strings and behavior unpacking can significantly change the visibility of a sample dynamic analysis helps confirm real system impact registry and file-system activity can reveal persistence or behavior that strings alone do not explain imported APIs can suggest behavior, but must be interpreted carefully disassembly and decompilation help connect observed behavior back to code structure anti-debugging behavior can change what an analyst sees binary analysis tools have different strengths, workflows, and learning curves malware reporting should be useful without exposing dangerous operational detail Why This Supports My Portfolio # This lab collection supports cybersecurity analyst, security operations, vulnerability management, incident response, and malware-analysis-aligned roles because it demonstrates the ability to:\ninvestigate suspicious files use multiple analysis tools connect static and dynamic findings interpret Windows behavior reason about malware capabilities write concise technical findings protect sensitive details when publishing work explain technical behavior in a recruiter-friendly and security-conscious way It also complements my ServiceNow SecOps and Vulnerability Response focus. Vulnerability management and security operations are stronger when an analyst understands how malicious code behaves after exploitation or initial execution.\nPortfolio-Safe Redaction Notes # This page intentionally excludes:\nraw malware samples exact executable files full crackme solution steps private screenshots full lab submissions detailed patching instructions sensitive hashes or infrastructure details instructor-provided files step-by-step misuse instructions The page keeps the emphasis on analysis method, tool exposure, reasoning process, and professional lessons learned.\nRelated Portfolio Areas # Security Operations # The labs connect directly to security operations work because they involve triage, evidence review, behavior analysis, and reporting.\nSOC-Relevant\nMalware Analysis # The course provided hands-on exposure to malware triage, packed executables, dynamic behavior, and reverse-engineering workflow.\nMalware Analysis\nReverse Engineering # IDA Pro, Ghidra, and Binary Ninja concepts helped connect low-level code structure to executable behavior.\nReverse Engineering\nPortfolio-Safe Publishing # The case study demonstrates how sensitive academic malware work can be summarized without exposing raw samples or full solutions.\nSecurity First\nNext Steps # This collection could be expanded later with:\nsanitized malware-analysis workflow diagrams a static-versus-dynamic analysis comparison table a safe reverse-engineering tool comparison a malware triage checklist a detection-engineering note based on behavioral indicators additional portfolio-safe lessons from crackme exercises For now, this page serves as the main public summary of the CYBER 366 Malware Analytics lab collection.\n","externalUrl":null,"permalink":"/research-labs/cyber-366-malware-analytics-reverse-engineering-lab-collection/","section":"Research \u0026 Labs","summary":"","title":"CYBER 366: Malware Analytics \u0026 Reverse Engineering Lab Collection","type":"research-labs"},{"content":"Web Design Case Study\nThis case study summarizes a Penn State web design final project focused on building a multi-page static website using HTML, CSS, JavaScript, navigation, image presentation, hover effects, product-style layouts, and user-facing site structure.\nType Academic Web Design Project Focus Multi-Page Static Website Technologies HTML · CSS · JavaScript Design Features Navigation · Images · Hover Effects · Product Tables Outcome Functional Bicycle Shop Website Portfolio Value Front-End Design Foundation Content Type: Academic Web Design Project / Front-End Development Case Study\nThis case study is based on a Penn State web design course final project. It has been summarized for portfolio use to demonstrate front-end development, visual design, layout structure, and interactive web design concepts.\nOverview # Uphill Struggle Bicycles was a multi-page website project built for a web design course at Penn State.\nThe project focused on creating a fictional bicycle shop website with separate pages for the homepage, mountain bikes, city bikes, and an about page. The site used custom HTML, CSS, image assets, navigation, product tables, hover styling, and JavaScript-based interaction.\nThis project is important to include in my portfolio because it shows early hands-on experience building a complete website structure from scratch before creating this current Hugo-based professional portfolio.\nProject Goals # The goal of the project was to design and build a functional static website with:\nmultiple linked pages a consistent navigation menu custom styling images and visual branding product-focused content sections responsive image behavior hover effects table-based product listings basic JavaScript interaction a polished visual theme Site Structure # The website included several main pages:\nHome Page # The home page introduced the fictional bicycle shop and highlighted both mountain bikes and city bikes.\nIt used large image sections, category links, background imagery, and promotional text to guide visitors toward the main product pages.\nMountain Bikes Page # The mountain bikes page presented a product-style table with bike images, descriptions, and prices.\nThe page included image hover behavior and dynamic text changes to make the product section more interactive.\nCity Bikes Page # The city bikes page followed a similar structure to the mountain bikes page, with a product table, bike images, pricing, hover behavior, and descriptive text.\nAbout Us Page # The about page included brand imagery, promotional content, a coupon-style list, and a flexbox-style image gallery using bike-related visuals.\nTechnologies Used # The project used:\nHTML CSS JavaScript custom image assets multi-page static site structure CSS hover effects fixed navigation responsive image sizing product tables flexbox-style gallery layout Design Features # Several design features from this project are still useful in my current portfolio work.\nFixed Navigation # The project used a fixed navigation bar so visitors could move between pages consistently.\nThis helped reinforce the importance of clear navigation and predictable site structure.\nImage-Driven Layout # The website used large bicycle images, background images, and visual category sections to make the site feel more like a real product-focused landing page.\nHover Effects # The project used hover effects for navigation, image scaling, border changes, and visual feedback.\nThis helped make the site feel more interactive and less static.\nJavaScript Interaction # The product pages included JavaScript that changed product descriptions when users hovered over bike images.\nThis introduced basic DOM interaction and showed how JavaScript can make static pages feel more dynamic.\nGallery Layout # The about page included a flexible image gallery layout, which helped demonstrate simple responsive layout thinking.\nWhat This Project Demonstrates # This project demonstrates hands-on experience with:\nbuilding a multi-page static website organizing HTML pages and assets applying custom CSS across multiple pages creating consistent navigation using image assets effectively designing product-style sections adding hover-based visual feedback writing basic JavaScript for interaction thinking about visual hierarchy and user navigation How This Influenced sudoRunner # This earlier web design project influenced how I think about my current portfolio.\nIdeas carried forward into sudoRunner include:\nclear navigation by category card-style content areas hover effects for interactive feedback visual hierarchy through headings and sections consistent styling across pages keeping the site easy for visitors to explore using design to support credibility, not distract from content What I Would Improve Today # If I rebuilt this project today, I would improve it by:\nusing more semantic HTML structure improving accessibility labels and contrast making the layout more responsive across screen sizes replacing repeated navigation markup with reusable templates improving the visual consistency of product cards using modern CSS grid more heavily reducing placeholder text improving mobile navigation separating JavaScript into its own file optimizing images for faster loading Portfolio Note # This project is included as a front-end development and web design case study.\nIt is not intended to represent a production business website. Instead, it demonstrates hands-on academic experience with HTML, CSS, JavaScript, layout design, navigation, image presentation, and interactive web page behavior.\n","externalUrl":null,"permalink":"/projects/uphill-struggle-bicycles-web-design-project/","section":"Projects","summary":"","title":"IST 250: Uphill Struggle Bicycles Web Design Project","type":"projects"},{"content":"Redacted Academic Case Study\nThis case study summarizes selected Penn State IST 311 academic work focused on Java programming, object-oriented design, data structures, algorithmic complexity, UML modeling, unit testing, debugging, and Git-based development workflow practice.\nType Academic Software Engineering Project Collection Focus Java Data Structures + OOP Foundations Concepts Lists · Queues · Trees · Graphs · Big-O Tools Java · IntelliJ IDEA · JUnit · Git Outcome Implemented and Analyzed Core Data Structures Privacy Level Redacted / No Raw Source Published Overview # This project collection summarizes selected academic work from IST 311, a software design and development course focused on programming foundations, object-oriented thinking, data structures, testing, debugging, and development workflow.\nThe purpose of including this collection in my portfolio is to show the software engineering foundation behind my cybersecurity, ServiceNow, vulnerability management, and technical lab work.\nThis page does not publish raw source archives, full academic submissions, or complete solution files. Instead, it summarizes the technical concepts, implementation areas, design work, and lessons learned in a portfolio-safe format.\nWhy This Matters # Cybersecurity work often requires more than tool usage. Strong analysts and consultants benefit from understanding how software is structured, how data moves through systems, how logic is tested, and how implementation decisions affect performance.\nThis project collection demonstrates foundational software engineering concepts that support:\nsecurity automation thinking vulnerability workflow design data structure reasoning debugging and troubleshooting script and code review platform configuration logic technical problem decomposition clearer communication with developers and engineering teams Concept Map # Java + OOP # Class design, methods, object relationships, encapsulation, and implementation logic.\nFoundation\nData Structures # Lists, queues, trees, heaps, graphs, nodes, edges, traversal, ordering, and relationships.\nCore Structures\nAlgorithms + Big-O # Access, search, insert, delete, recursion, traversal, and performance tradeoffs.\nComplexity\nUML + CRC Design # Class diagrams, responsibilities, collaborators, attributes, methods, and system modeling.\nDesign Thinking\nTesting + Debugging # JUnit exposure, breakpoints, runtime inspection, expected behavior, and implementation validation.\nValidation\nGit Workflow # Local repository setup, version-controlled development, and structured project workflow.\nDeveloper Workflow\nWork Included # Java Data Structures # This project collection included work with several core data structures and related implementation concepts:\narrays linked lists doubly linked lists stacks queues binary search trees red/black trees heaps graphs The work reinforced how different data structures affect access, search, insert, delete, traversal, ordering, and performance.\nDoubly Linked List Operations # I created visual and implementation-focused work around doubly linked list operations, including:\nappend insert delete push pop search previous and next node relationships time complexity reasoning This helped reinforce how pointer-style relationships affect insertion, deletion, traversal, and search behavior.\nQueue Implementation # I worked on queue implementation concepts using Java, including node-based ordering, enqueue/dequeue behavior, and first-in, first-out logic.\nThis reinforced the importance of predictable data flow and helped connect abstract data structures to practical workflow design.\nBinary Search Tree Implementation # I worked with binary search tree concepts including insertion, recursive search, traversal, validation, and recovery logic.\nThe implementation work included concepts such as:\nadding nodes recursively searching for target values in-order traversal validating whether a tree follows BST ordering rules identifying invalid node relationships swapping node values attempting to repair a damaged tree structure This helped reinforce recursive reasoning, tree ordering, and how structural assumptions affect correctness.\nBinary Search Tree Operations # I also created diagram-based work showing common binary search tree operations, including:\ninserting into an empty tree inserting into a balanced tree inserting into a poorly balanced tree deleting elements deleting leaf nodes deleting nodes with children searching for values A key lesson from this work was understanding that balanced trees can support efficient search behavior, while poorly balanced trees can degrade toward linked-list-like performance.\nRed/Black Tree Operations # I created a red/black tree operations diagram showing insertion, deletion, search, color balancing, and rotation-related concepts.\nThis helped connect tree-balancing rules to performance and reinforced why self-balancing trees are useful when predictable search efficiency matters.\nHeap and Graph Concepts # The broader IST 311 work also included heap and graph-related practice.\nGraph-related work reinforced how vertices, edges, and relationships can model connected systems. This is especially relevant to cybersecurity because many security problems involve relationships between users, systems, services, assets, permissions, and network paths.\nHeap-related work reinforced priority-oriented structure and helped support broader algorithmic reasoning.\nBig-O Complexity Analysis # I created Big-O analysis work comparing common data structures and reasoning through which structures fit different problems.\nExamples included:\nusing a stack-like structure for browser back functionality using list or tree-style structures for game move modeling using graph structures to represent social network relationships comparing access, search, insert, and delete behavior across different data structures This helped reinforce that implementation choices should be based on expected operations, not just convenience.\nUML and Object-Oriented Design # The course also included UML and class design work.\nI worked with LMS-style class modeling involving concepts such as:\ncourses assignments professors attributes methods class relationships responsibility boundaries This supported object-oriented thinking and helped reinforce how systems can be broken into classes, responsibilities, and interactions.\nCRC Cards # I also practiced CRC card modeling.\nCRC cards helped organize:\nclass responsibilities class collaborators how system objects interact where behavior belongs how responsibilities should be separated This was useful because it shifted the focus from just writing code to thinking about design responsibility and collaboration between components.\nGit and Development Workflow # The course included Git and local repository workflow practice.\nThis included setting up a local development environment, using Git tooling, working in IntelliJ IDEA, and building habits around version-controlled development.\nDebugging and Unit Testing # The work included debugging practice in IntelliJ IDEA and exposure to test-oriented development workflows.\nThis helped reinforce:\nbreakpoint-based debugging inspecting values at runtime understanding program state validating expected behavior using tests to support implementation confidence Skills Demonstrated # This project collection demonstrates:\nJava programming fundamentals object-oriented programming class and method design UML interpretation and modeling CRC card modeling data structure implementation algorithmic complexity reasoning recursive problem solving debugging with breakpoints unit testing exposure Git setup and version-control workflow technical diagramming academic project documentation problem-to-structure analysis Security Relevance # Although this was not a cybersecurity-specific project, the concepts are directly useful in cybersecurity work.\nData structures, debugging, workflow logic, testing, and object-oriented thinking support:\nunderstanding application behavior reading and interpreting code writing small automation scripts reasoning about performance troubleshooting technical workflows understanding how platform logic is structured communicating technical implementation details clearly analyzing how data relationships appear in systems thinking through how security tools organize findings, assets, users, and events For ServiceNow SecOps and Vulnerability Response work specifically, this kind of foundation supports understanding how records, relationships, workflows, assignment logic, and remediation states are structured inside a platform.\nWhat I Would Improve Today # If I revisited this work today, I would improve it by:\nadding cleaner README files for each implementation separating production code and test code more consistently improving naming conventions adding more unit tests and edge cases documenting expected inputs and outputs adding diagrams directly into project README files using Git branches and commit history more intentionally removing IDE-specific files from any public repository improving code comments where needed connecting data structure behavior to cybersecurity use cases adding small security-focused examples, such as asset graphs or vulnerability-priority queues Portfolio Note # This page is a sanitized case study.\nRaw source files, full academic submissions, private filenames, screenshots with personal identifiers, and full solution archives are not published. The purpose is to demonstrate foundational software engineering knowledge without turning the portfolio into a homework repository.\n","externalUrl":null,"permalink":"/projects/java-data-structures-software-engineering-foundations/","section":"Projects","summary":"","title":"IST 311: Java Data Structures, OOP \u0026 Software Engineering Foundations","type":"projects"},{"content":" Portfolio Gallery\nThis section focuses on operational technology, industrial control systems, cyber-physical risk, and the security challenges that exist where cybersecurity meets real-world operations.\nMy interest in OT/ICS security comes from academic exposure to ICS and SCADA concepts in simulated smart grid and lab environments, where cybersecurity risk must be understood alongside availability, safety, uptime, and operational continuity.\nOT/ICS focus: These pages emphasize operational impact, asset context, safety awareness, recovery validation, and risk communication — not just traditional IT vulnerability severity.\nFeatured Case Studies # ICS IT/OT Application-Level DoS Attack Lab # A redacted academic lab case study focused on investigating and recovering from an application-level denial-of-service condition affecting a SCADA/OT environment.\nOT/ICS SCADA Lab Recovery Validation Using AI to Translate Vulnerability Risk Between Cybersecurity and OT Operations Teams # A concept note exploring how AI could help translate vulnerability findings into operationally meaningful language for OT, ICS, cybersecurity, and business stakeholders.\nAI Concept Risk Translation Focus Areas # Cyber-Physical Risk # OT/ICS security is not only about vulnerabilities and technical findings. It is also about understanding how cyber risk can affect physical processes, operations, safety, uptime, and business continuity.\nOperational Impact\nRisk Frameworks # Notes and projects related to frameworks such as NIST CSF and IEC 62443, especially where they apply to industrial environments and operational security programs.\nNIST CSF / IEC 62443\nSmart Grid and Critical Infrastructure Concepts # Writeups related to smart grid security, industrial network segmentation, control system risk, asset context, and the unique challenges of securing operational environments.\nSmart Grid\nTranslating Cybersecurity for Operations Teams # A major challenge in OT/ICS security is communicating technical findings in a way that engineers, operators, and business stakeholders can act on.\nRisk Communication\nPlanned Articles # What Makes OT/ICS Security Different from Traditional IT Security # A planned writeup explaining how availability, safety, physical processes, maintenance windows, and vendor constraints change the security conversation.\nPlanned\nWhy Asset Context Matters in Industrial Vulnerability Management # A planned article focused on why CVSS alone is not enough when an affected asset supports operational processes.\nPlanned\nIEC 62443 Notes for Early-Career Cybersecurity Professionals # A planned notes page for organizing early-career learning around industrial cybersecurity principles and controls.\nPlanned\n","externalUrl":null,"permalink":"/ot-ics-security/","section":"IST 451: ICS/IT-OT Application-Level DoS Attack Lab","summary":"","title":"IST 451: ICS/IT-OT Application-Level DoS Attack Lab","type":"ot-ics-security"},{"content":"OT/ICS Case Study\nThis case study summarizes a redacted Penn State OT/ICS lab focused on investigating an application-level denial-of-service condition affecting SCADA visibility, identifying the source of disruptive activity, stopping the responsible process, and validating operational recovery.\nType OT/ICS Academic Lab Focus SCADA Visibility Disruption Concepts PLC · Modbus · HMI · DoS Role Incident Investigator Outcome Attack Stopped + Measurements Restored Privacy Level Redacted / No Raw Lab Details Published Content Type: Redacted Academic Lab / OT/ICS Security Case Study\nThis case study is based on academic lab work completed at Penn State. It has been rewritten and sanitized for portfolio use. It does not include raw screenshots, lab instructions, internal IP details, student identifiers, or step-by-step attack instructions.\nOverview # This lab focused on investigating an application-level denial-of-service condition affecting an ICS/OT environment.\nThe scenario involved a SCADA-facing environment where normal measured values were disrupted during an attack. The objective was to investigate the source of the disruption, identify the system and process responsible, stop the attack, and confirm that operational measurements returned to normal.\nWhy This Lab Matters # OT and ICS environments are different from traditional IT systems because cybersecurity events can affect visibility, uptime, process continuity, and operational decision-making.\nIn this lab, the issue was not just that network traffic was suspicious. The more important concern was that the SCADA environment stopped displaying expected values during the attack condition. That makes the incident operationally meaningful, not just technically interesting.\nEnvironment and Concepts # This lab involved concepts related to:\nSCADA monitoring HMI client visibility PLC communication Modbus server connections Application-level denial-of-service behavior Network connection analysis Workstation investigation Process identification Operational recovery validation My Role # For this lab, I acted as the analyst investigating the OT/ICS disruption.\nThe work involved:\nObserving normal measured values in the SCADA interface Identifying the point where measurements stopped displaying correctly Reviewing network connections related to the affected PLC Determining which workstation generated suspicious connections Investigating processes responsible for the connections Stopping the malicious activity in the lab environment Confirming that measured values returned to normal after remediation Investigation Summary # 1. Establishing Normal Conditions # The lab began by observing normal measured values in the SCADA interface.\nThis step was important because the analyst needed a baseline before determining whether the environment was degraded or disrupted.\n2. Observing the Disruption # After the attack condition began, the SCADA interface stopped displaying the expected values.\nFrom an OT perspective, this is significant because loss of visibility can interfere with operator awareness, monitoring, and operational confidence.\n3. Reviewing Network Connections # The next phase focused on examining active network connections involving the affected PLC and Modbus communication.\nThe investigation showed that additional connections were interfering with normal communication behavior.\n4. Identifying the Suspect Workstation # The lab required tracing the suspicious connections back to the system responsible for generating the traffic.\nThis step demonstrated the importance of moving from symptom-level observation to source identification.\n5. Identifying the Responsible Process # After identifying the suspect system, the next step was to determine which running process was responsible for the network activity.\nThis reinforced an important incident response principle: identifying the host is not enough. The analyst also needs to understand what process or program is causing the behavior.\n6. Stopping the Attack and Validating Recovery # After stopping the responsible activity in the lab environment, the SCADA interface was checked again to confirm that measured values returned to normal.\nThis validation step matters because remediation should not stop at “the suspicious process was killed.” In an OT/ICS context, the analyst must confirm that operational visibility and expected behavior have been restored.\nWhat This Lab Demonstrates # This lab demonstrates hands-on academic exposure to:\nOT/ICS incident investigation SCADA visibility concerns PLC and Modbus communication concepts Application-level denial-of-service impact Network connection review Suspect workstation identification Malicious process investigation Recovery validation Translating technical evidence into operational impact Lessons Learned # The most important lesson from this lab is that OT/ICS security requires both technical investigation and operational awareness.\nIn a traditional IT environment, a denial-of-service event may be discussed primarily in terms of service availability. In an OT/ICS environment, the same kind of disruption can affect operator visibility, monitoring confidence, and process awareness.\nThis lab also reinforced the importance of validating recovery. Stopping suspicious activity is only one part of incident response. Analysts also need to confirm that the affected system or process has returned to expected behavior.\nWhat I Would Improve # If I expanded this lab into a larger portfolio project, I would add:\nA simplified network diagram A defensive detection summary A short incident response timeline A mapping of observed behavior to OT/ICS risk A high-level detection logic concept A recovery checklist for similar SCADA visibility issues A comparison between IT-style DoS impact and OT/ICS operational impact Portfolio Note # This page is intentionally written as a sanitized case study. The original lab report is not published because it contains course metadata, screenshots, lab-specific details, and raw procedural content that is not necessary for employer review.\nThe goal is to demonstrate understanding of OT/ICS security investigation, operational impact, and recovery validation without exposing unnecessary technical or academic details.\n","externalUrl":null,"permalink":"/ot-ics-security/ics-it-ot-application-level-dos-lab/","section":"IST 451: ICS/IT-OT Application-Level DoS Attack Lab","summary":"","title":"IST 451: ICS/IT-OT Application-Level DoS Attack Lab","type":"ot-ics-security"},{"content":"Defensive Security Case Study\nThis case study summarizes a redacted Penn State malware investigation lab focused on suspicious traffic analysis, firewall log review, containment, spoofing indicators, packet capture review, malicious process identification, and defensive validation.\nType Malware Investigation Lab Focus Suspicious Traffic + Containment Methods Firewall Logs · Packet Capture · Host Review Concepts Spoofing · ARP Scan Behavior · Process Identification Outcome Malicious Activity Identified + Neutralized Privacy Level Redacted / No Raw Lab Details Published Content Type: Redacted Academic Lab / Defensive Security Case Study\nThis case study is based on academic lab work completed at Penn State. It has been rewritten and sanitized for portfolio use. It does not include raw screenshots, lab instructions, student identifiers, internal IP details, or step-by-step offensive procedures.\nOverview # This lab focused on investigating and neutralizing suspicious network activity caused by a malware-based attack in a controlled academic environment.\nThe objective was to identify the source of suspicious traffic, block malicious communication, investigate the affected host, determine whether spoofing was involved, locate the malicious process, and validate that the activity was neutralized.\nWhy This Lab Matters # Malware investigations require more than simply seeing suspicious traffic.\nA security analyst needs to move from alert or log evidence to source identification, host investigation, process review, containment, and validation. This lab helped reinforce that defensive workflow.\nThe case also demonstrated that traffic source information may be misleading when spoofing is involved. That makes correlation between firewall logs, packet captures, host-level commands, and process information important.\nEnvironment and Concepts # This lab involved concepts related to:\nFirewall log review Suspicious network traffic investigation Traffic blocking and containment Host investigation Packet capture review Source IP spoofing Process identification Malware process termination ARP scan behavior Defensive validation My Role # For this lab, I acted as the analyst responsible for investigating and containing the suspicious activity.\nThe work involved:\nReviewing firewall logs for suspicious traffic Identifying traffic moving toward an unexpected network segment Blocking suspicious traffic Investigating the suspected source host Comparing IP and MAC address evidence Reviewing packet capture data Identifying evidence of spoofed source behavior Locating the malicious process Stopping the process in the lab environment Reviewing the malicious program behavior at a high level Investigation Summary # 1. Identifying Suspicious Traffic # The investigation began by reviewing firewall logs to identify traffic moving from an internal user network toward an unexpected destination network.\nThis step established the initial indicator that something abnormal was occurring and provided a starting point for containment and investigation.\n2. Blocking Suspicious Communication # After identifying suspicious traffic, the lab required blocking traffic toward the suspicious destination.\nThis represented a containment step: reducing exposure while the analyst continued investigating the root cause.\n3. Investigating the Suspected Source # The next step was to investigate the host believed to be generating the suspicious traffic.\nThis included reviewing host-level information and comparing network evidence against what was observed from firewall and packet data.\n4. Reviewing Spoofing Indicators # The lab showed that the apparent source information did not fully align across the investigation.\nThis raised the possibility that the traffic involved source spoofing. In a real investigation, this would be important because relying on one log source alone could lead the analyst to the wrong conclusion.\n5. Packet Capture Review # Packet capture data was used to gather more evidence about the suspicious traffic.\nThis helped move the investigation beyond surface-level firewall logs and supported a more complete understanding of what was happening on the network.\n6. Identifying and Stopping the Malicious Process # After host and network review, the lab focused on identifying the process responsible for the suspicious activity.\nStopping the malicious process represented the remediation step in the controlled lab environment.\n7. Reviewing Malicious Behavior # The malicious program was reviewed at a high level to understand its behavior. The lab identified ARP scan behavior, which helped explain the nature of the suspicious activity.\nWhat This Lab Demonstrates # This lab demonstrates hands-on academic exposure to:\nDefensive malware investigation Firewall-based traffic analysis Suspicious traffic containment Host-level investigation Packet capture interpretation IP/MAC evidence comparison Source spoofing analysis Malicious process identification Malware neutralization in a lab environment Communicating technical findings as an incident workflow Lessons Learned # The most important lesson from this lab is that incident response requires evidence correlation.\nFirewall logs, packet captures, host-level observations, process data, IP addresses, and MAC addresses each provide part of the story. A good analyst needs to connect those pieces before making a conclusion.\nThe lab also reinforced the importance of containment. Blocking suspicious communication can reduce immediate risk while the analyst continues investigating the affected system.\nFinally, the lab showed that malware behavior may not be obvious from one viewpoint. Host investigation and packet-level review can reveal details that firewall logs alone may miss.\nWhat I Would Improve # If I expanded this lab into a larger portfolio project, I would add:\nA simplified incident timeline A defensive investigation flowchart A list of key evidence sources A sanitized packet-analysis summary A containment and eradication checklist A short detection logic concept A mapping of the workflow to incident response phases A lessons-learned section focused on analyst decision-making Portfolio Note # This page is intentionally written as a sanitized case study. The original lab report is not published because it contains course metadata, lab screenshots, internal lab details, and raw procedural content.\nThe goal is to demonstrate defensive investigation, malware analysis workflow, containment thinking, and security operations reasoning without exposing unnecessary technical or academic details.\n","externalUrl":null,"permalink":"/projects/malware-based-attack-investigation-lab/","section":"Projects","summary":"","title":"IST 451: Malware-Based Attack Investigation Lab","type":"projects"},{"content":"Content Type: Redacted Academic Lab Collection\nThis collection is based on academic cybersecurity lab work completed at Penn State. It has been rewritten and sanitized for portfolio use. It does not include raw screenshots, student identifiers, lab IP addresses, credentials, full commands, exploit steps, or procedural offensive details.\nOverview # This lab collection represents hands-on cybersecurity coursework focused on defensive analysis, secure configuration, vulnerability assessment, incident investigation, network security, OT/ICS security, and controlled lab-based security testing.\nThe goal of this page is to summarize the technical breadth of the lab work without publishing raw submissions or step-by-step attack instructions.\nLab Coverage # Service Identification # This lab focused on identifying services and host characteristics in a controlled network environment.\nKey concepts included:\nTCP scanning UDP scanning NetBIOS information gathering operating system identification interpreting network service exposure Secure Apache Web Server Configuration # This lab focused on web server hardening concepts using Apache.\nKey concepts included:\nsecure configuration review reducing unnecessary exposure web server security controls configuration validation defensive system administration Vulnerability Scanning with OpenVAS # This lab focused on vulnerability assessment using OpenVAS.\nKey concepts included:\nvulnerability scanning interpreting scanner results identifying exposed services reviewing severity and remediation context understanding how vulnerability findings support risk reduction SQL Injection Detection and Exploitation Concepts # This lab focused on understanding SQL injection risk in a controlled academic environment.\nKey concepts included:\ninput validation weaknesses database-backed web application risk identifying injection behavior understanding impact defensive lessons for secure application design This lab is summarized at a high level only. The purpose is to demonstrate application security awareness, not to publish exploit instructions.\nMalware-Based Attack Investigation # This lab focused on investigating and neutralizing suspicious traffic caused by a malware-based attack in a controlled environment.\nKey concepts included:\nfirewall log review suspicious traffic blocking host investigation packet capture review source spoofing indicators malicious process identification ARP scan behavior containment and validation A dedicated sanitized case study is available here:\nMalware-Based Attack Investigation and Neutralization Lab\nICS IT/OT Application-Level DoS Investigation # This lab focused on an application-level denial-of-service condition affecting a SCADA/OT environment.\nKey concepts included:\nRapidSCADA visibility HMI monitoring PLC communication Modbus server connections identifying the suspect workstation process investigation stopping disruptive activity validating that measured values returned to normal A dedicated sanitized case study is available here:\nICS IT/OT Application-Level DoS Attack Lab\nIntro IDS Configuration with Snort # This lab focused on introductory intrusion detection system configuration using Snort.\nKey concepts included:\nIDS configuration rule-based detection concepts alerting logic network monitoring understanding how detection supports security operations Firewall Configuration with iptables # This lab focused on firewall rule configuration using iptables.\nKey concepts included:\npacket filtering traffic allow/block decisions rule ordering host-based firewall logic basic Linux network security controls Wireless Security and 4-Way Handshake Concepts # This lab focused on wireless security concepts in a controlled academic environment.\nKey concepts included:\nwireless authentication EAPOL traffic review 4-way handshake analysis Wireshark packet inspection password security considerations wireless defensive lessons This lab is summarized at a high level only. The goal is to demonstrate understanding of wireless security mechanics and defensive implications.\nControlled Capture-the-Flag Scenario # This lab involved a controlled CTF-style environment used to practice security testing methodology.\nKey concepts included:\nnetwork discovery service enumeration web path discovery credential risk awareness post-compromise impact understanding privilege escalation concepts security testing documentation This lab is intentionally summarized without procedural details, commands, payloads, or exploitation steps. The purpose is to show controlled lab exposure and security testing awareness, not to provide instructions.\nSkills Demonstrated # Across the lab collection, these exercises demonstrate hands-on exposure to:\nnetwork reconnaissance service identification vulnerability scanning web application security malware investigation packet analysis firewall rule configuration IDS concepts OT/ICS security investigation wireless security fundamentals incident response thinking security testing methodology defensive validation and documentation Defensive Takeaways # Several important cybersecurity lessons stood out across the labs.\nFirst, visibility matters. Tools such as packet captures, firewall logs, IDS alerts, vulnerability scans, and host-level process review each provide a different view of security activity.\nSecond, findings need context. A scanner result, open service, suspicious packet, or unusual process is only useful when an analyst can connect it to risk, ownership, and next steps.\nThird, controlled offensive labs can strengthen defensive understanding. Learning how attacks work in a safe lab environment helps security professionals better understand prevention, detection, containment, and recovery.\nFourth, OT/ICS environments require operational awareness. Security events in industrial or cyber-physical environments can affect visibility, uptime, process continuity, and operator confidence.\nPortfolio Note # This page is intentionally written as a sanitized academic lab collection. The original lab reports are not published because they contain course metadata, screenshots, lab-specific infrastructure details, and procedural content that is not necessary for employer review.\nThe purpose of this collection is to show technical breadth, hands-on cybersecurity exposure, and the ability to translate lab work into professional security lessons.\n","externalUrl":null,"permalink":"/research-labs/ist-451-security-labs-collection/","section":"Research \u0026 Labs","summary":"","title":"IST 451: Security Labs Collection","type":"research-labs"},{"content":"Opportunity Fit\nThis page is for recruiters, hiring managers, and technical reviewers who want the quick answer:\nBest fit: ServiceNow SecOps, Vulnerability Response, vulnerability management, cybersecurity analyst work, security operations, and GRC-aware security roles.\nI am not trying to present myself as an expert in every area on this site. The portfolio is broad because my academic background covered a lot: incident response, malware analysis, forensics, cloud, risk, HCI, software, and OT/ICS. The center of gravity is still clear: ServiceNow SecOps and cybersecurity operations.\nStrongest Role Fit # ServiceNow SecOps Consultant # This is the strongest fit.\nThe work I want to keep building on is ServiceNow SecOps and Vulnerability Response: vulnerable item workflow, assignment ownership, remediation tracking, validation, exception handling, closure, requirements, UAT, training support, and client communication.\nPrimary Fit\nVulnerability Management Analyst # Strong fit because much of my ServiceNow and academic work maps to the same question: what needs to be fixed, who owns it, how should it be prioritized, and how do we confirm it is closed?\nStrong Fit\nCybersecurity Analyst # Strong fit for analyst roles involving security operations, incident response support, log review, malware triage, network traffic analysis, forensic evidence, and written reporting.\nStrong Fit\nGRC-Aware Security Analyst # Good fit where the role needs technical security awareness plus risk, policy, privacy, decision-making, documentation, and stakeholder communication.\nGood Fit\nGood Developing Fit # OT/ICS Security Analyst # Developing fit.\nI have academic OT/ICS evidence and a strong interest in cyber-physical systems, SCADA/PLC concepts, operational disruption, availability, and recovery validation. I would be strongest in a junior, analyst, or hybrid role where I can keep building hands-on OT depth.\nDeveloping Specialty\nCloud Security / Infrastructure Security Analyst # Developing fit.\nIST 402 gave me practical exposure to Hyper-V, OpenStack, Docker, Docker Compose, mutual TLS, zero trust concepts, Wazuh/OpenSCAP, shared responsibility, and SECaaS strategy. I can discuss the concepts, but I would not present cloud security as my deepest area yet.\nDeveloping Area\nIncident Response / Forensics Support # Good fit for roles where incident response and forensics are part of a broader analyst function.\nCYBER 440 and IST 454 give me strong academic evidence, but I would frame this as analyst-level or support-level experience, not senior DFIR experience.\nAcademic Strength\nWhat I Would Lead With # Opportunity Type Best Evidence Why It Fits ServiceNow SecOps / VR ServiceNow SecOps Lab Hub and VR Triage Checklist Primary Cybersecurity Analyst CYBER 440 Capstone, CYBER 366 Malware Analytics, and IST 456 Security \u0026 Risk Management Strong Incident Response / Forensics CYBER 440, IST 454, and CYBER 342W Academic Evidence GRC / Risk IST 456, IST 432, SRA 311, and SRA 231 Risk-Aware OT/ICS Security OT/ICS Security and IST 451 ICS/IT-OT DoS Lab Developing Technical Documentation / Networking IST 495 Network Lab Development Internship Professional Experience Role Fit by Strength # Role Fit Reason ServiceNow SecOps Consultant Very strong fit. This aligns with my professional experience, current direction, portfolio structure, and strongest workflow evidence. Best Fit Vulnerability Response / Vulnerability Management Analyst Strong fit. I can connect vulnerable item handling, remediation ownership, risk review, validation, exception handling, and closure. Strong Fit Cybersecurity Analyst / SOC Analyst Strong fit for junior or early-career analyst roles. Evidence includes SIEM-style investigation, malware analysis, traffic analysis, forensics, and reporting. Strong Fit Incident Response Analyst Good fit for support or junior-level IR work. CYBER 440 and CYBER 342W show both investigation and response planning, but I would not oversell this as senior DFIR experience. Good Fit GRC / Security Risk Analyst Good fit where technical security knowledge needs to be paired with policy, risk analysis, compliance awareness, and communication. Good Fit OT/ICS Security Analyst Developing fit. I have genuine interest and academic evidence, but I would position this as a growth area unless the role is entry-level or hybrid. Developing Software Developer Supporting fit, not primary. I have Java/OOP/application development foundations, but I am not positioning myself as a pure software developer. Supporting What Makes Me Different # I understand workflow. # A lot of my best work is not just tool usage. It is workflow: intake, triage, ownership, remediation, validation, documentation, and closure.\nProcess-Oriented\nI can connect technical and business language. # The portfolio includes malware, forensics, and SIEM work, but also risk, privacy, cyber law, DR/BC, decision theory, and communication-heavy coursework.\nTechnical + Risk\nI care about usability. # IST 331 and the work on this portfolio show that I pay attention to navigation, user flow, visual hierarchy, and whether people can actually use the system.\nHCI-Aware\nI publish carefully. # A lot of my work involves sensitive areas: malware, forensics, security labs, academic files, and simulated evidence. I summarize the work without dumping raw artifacts.\nSecurity First\nLess Ideal Fits # These are not impossible, but they are not the roles I would lead with right now.\nRole Type Why Not First Choice Status Pure Software Engineering I have application development coursework, but my strongest professional direction is cybersecurity and ServiceNow SecOps. Not Primary Senior DFIR / Malware Reverse Engineer I have strong academic evidence, but I would not claim senior-level DFIR or malware reverse engineering experience. Not Yet Pure Cloud Engineer IST 402 gives me cloud and container exposure, but cloud engineering is not the main direction of the portfolio. Supporting Quick Links # Resume ServiceNow SecOps Projects Contact ","externalUrl":null,"permalink":"/opportunity-fit/","section":"","summary":"","title":"Opportunity Fit","type":"page"},{"content":"Portfolio Changelog\nThis page tracks meaningful changes to sudoRunner.\nI am treating the site like a real portfolio product: content is added, reviewed, renamed, reorganized, and cleaned up over time. The goal is not just to keep adding pages. The goal is to make the site easier to review, more honest, more usable, and more useful for ServiceNow SecOps, cybersecurity, GRC, and technical reviewers.\nWhy this page exists: The changelog shows how the portfolio has evolved: new evidence added, pages reorganized, HCI issues fixed, course-coded naming normalized, and sensitive work kept portfolio-safe.\nJune 2026 # Update What Changed Area Homepage Redesign Reworked the homepage so the review path is clearer. “Start Here” is now the obvious primary action, with secondary actions and featured areas centered underneath. HCI Course-Coded Project Naming Normalized academic project names across the site so projects consistently use course codes such as CYBER 440, CYBER 366, IST 456, IST 454, SRA 311, IST 331, and IST 495. Content Cleanup Project Gallery Rebuild Reorganized the Projects page so the strongest evidence appears first, followed by supporting incident response, forensics, malware, GRC, cloud, HCI, software, and foundational work. Projects Capabilities Page Rebuild Rebuilt the capability map so it connects specific skills to specific evidence instead of reading like a generic skills list. Evidence Map Review Paths Rewrite Rewrote role-based review paths for recruiters, ServiceNow reviewers, cybersecurity analysts, incident response reviewers, GRC reviewers, OT/ICS reviewers, cloud reviewers, and HCI/software reviewers. Navigation Start Here Rewrite Turned Start Here into a true front desk for the portfolio, with a clear fast review path and guidance on what to read first. Reviewer Flow Research \u0026 Labs Cleanup Separated Research \u0026 Labs from the main Projects page so it focuses on ServiceNow SecOps, Vulnerability Response, CYBER 366, CYBER 262, and IST 451 lab work. Research Labs Resume, About, Credentials, and Opportunity Fit Rewrites Updated the high-traffic personal pages so they sound more direct, less generic, and more honest about primary strengths, supporting areas, and developing interests. Core Pages New Portfolio Evidence Added # CYBER 440: Cybersecurity Capstone Incident Response \u0026amp; Forensics # Added a capstone investigation page covering phishing, malware activity, forensic images, memory artifacts, logs, incident timeline development, impact assessment, and remediation planning.\nFlagship Evidence\nCYBER 342W: Incident Response, Disaster Recovery \u0026amp; Business Continuity Planning # Added an incident response planning page focused on NIST 800-61, CSIRT structure, communication, containment, recovery, disaster recovery, business continuity, and cybersecurity writing.\nIR Planning\nCYBER 366: Malware Analytics \u0026amp; Reverse Engineering Lab Collection # Added malware analysis evidence covering static analysis, dynamic analysis, unpacking, FLOSS, PE review, ProcMon, RegShot, IDA Pro, Ghidra, Binary Ninja, and anti-debugging awareness.\nMalware Analysis\nIST 454: Computer \u0026amp; Cyber Forensics Lab Evidence # Added selected forensics evidence covering image creation, image mounting, hash verification, registry analysis, data carving, deleted file recovery, and AI/IoT forensics research.\nForensics\nIST 456: Security \u0026amp; Risk Management with Enigma Glass Labs # Added security risk management evidence covering Enigma Glass SIEM-style investigation, ransomware, compromised credentials, data exfiltration, ISO 27000 concepts, compliance, and contingency planning.\nRisk / GRC\nIST 495: Penn State College of IST Network Lab Development Internship # Added professional internship evidence covering networking lab modernization, technical research, lab validation, documentation, rubrics, teamwork, and supervisor-facing communication.\nInternship\nAdditional Academic Evidence Added # Page Why It Was Added Area IST 432: Cyber Law, Privacy \u0026 GRC Case Analysis Adds cyber law, privacy, surveillance, CFAA, cybersquatting, digital governance, and cybercrime analysis. GRC SRA 311: Risk Analysis in a Security Context Adds risk analysis, source credibility, analytic confidence, weighted ranking, threat modeling, and risk treatment. Risk Analysis SRA 231: Decision Theory \u0026 Analysis for Security Reasoning Adds decision theory, decision matrices, decision trees, risk/ignorance, expected value, group decisions, and behavioral decision-making. Decision Theory IST 402: Cloud Virtualization, Containers \u0026 SECaaS Architecture Adds cloud, virtualization, containers, OpenStack, Docker, mTLS, zero trust concepts, workflow modeling, and SECaaS strategy. Cloud Security IST 331: User-Centered Design \u0026 Booking.com Redesign Adds the HCI evidence behind the portfolio’s usability focus: user research, Figma prototypes, usability testing, and iterative redesign. HCI SRA 221: Information Security Foundations Lab Collection Adds early information security tool exposure: OWASP ZAP, Wireshark, SPARTA, OpenVPN, pfSense, Active Directory, file system forensics, and Splunk. Foundations Software and Application Development Evidence Added # Page Why It Was Added Area IST 261: Productivity Assistant Application Design Studio Adds application design studio evidence: proposal, noun/verb analysis, OOP model, MVC, persistence, task queues, GUI workflow, and testing. Application Design IST 242: Intermediate Java \u0026 Object-Oriented Application Development Adds intermediate Java evidence: inheritance, abstract classes, interfaces, polymorphism, Swing GUI, validation, and application structure. Intermediate Java IST 240: Introductory Java Programming \u0026 OOP Lab Progression Adds introductory Java progression: class design, constructors, methods, encapsulation, arrays, ArrayLists, inheritance, and model/data separation. Java Basics HCI and Branding Fixes # Fix What Changed Area Clickable vs Static Elements Improved the distinction between real buttons, links, status labels, badges, honors, and static information panels. Usability Credential Layout Reworked education, credentials, honor societies, and certifications into cleaner static panels and record rows. Credentials Cum Laude Styling Fixed inconsistent Cum Laude styling so it appears as academic honor text instead of a fake button or badge. Visual Polish Contact Page Cleaned up the contact page so contact methods read as structured contact records instead of broken or fake button elements. Contact UX Favicon / Brand Fix Replaced the default Blowfish browser favicon with the sudoRunner terminal-style icon. Branding Mobile Layout Cleanup Improved mobile layout behavior, spacing, card stacking, button visibility, and safe-area handling across key pages. Mobile HCI Current Direction # Keep the hierarchy honest. # Not every page is a flagship project. Some pages show strong evidence; others show foundations and progression. The site should make that clear.\nEvidence Hierarchy\nKeep the voice human. # The portfolio should sound like my work, not generic brochure copy. Strong pages should explain what I actually did and why it matters.\nHuman Voice\nKeep publishing carefully. # The site should show meaningful cybersecurity work without exposing raw malware, forensic evidence, private lab files, full academic answers, credentials, or client-sensitive information.\nSecurity First\n","externalUrl":null,"permalink":"/changelog/","section":"","summary":"","title":"Portfolio Changelog","type":"page"},{"content":"Public Resume\nI am a U.S. citizen and Penn State Cybersecurity Analytics \u0026amp; Operations graduate focused on ServiceNow SecOps, Vulnerability Response, cybersecurity operations, vulnerability management, and OT/ICS security.\nThis page is the quick version. The project pages show the evidence behind it.\nDownload Resume PDF Projects Capabilities Contact Privacy note: This is the public version of my resume. It uses a professional contact alias and omits private contact details.\nProfessional Focus # ServiceNow SecOps # My strongest career focus is ServiceNow SecOps and Vulnerability Response: vulnerable item workflow, ownership, remediation tracking, exception handling, validation, and closure.\nPrimary Focus\nCybersecurity Operations # My academic and project work covers incident response, malware analysis, forensics, SIEM-style investigation, network traffic analysis, endpoint behavior, and analyst-style reporting.\nSecurity Operations\nGRC-Aware Risk Analysis # I have supporting work in security risk management, cyber law, privacy, decision theory, incident planning, business continuity, and risk treatment.\nRisk-Aware\nOT/ICS Security # I am interested in operational technology and industrial control systems security, especially cyber-physical risk, availability, operational disruption, and recovery validation.\nSpecialty Interest\nEducation # The Pennsylvania State University # B.S. Cybersecurity Analytics \u0026amp; Operations\nGraduated Cum Laude\nGPA: 3.88\nFocus Area: Application Development\nAcademic Honors: The Honor Society of Phi Kappa Phi · Alpha Sigma Lambda Honor Society\nCompleted Application Development Focus Phi Kappa Phi Alpha Sigma Lambda Credentials # Credential Code / Detail Status ServiceNow Certified System Administrator CSA · scheduled June 2026 Scheduled ISC2 Certified in Cybersecurity CC Completed Microsoft Azure Fundamentals AZ-900 Completed Microsoft Security, Compliance, and Identity Fundamentals SC-900 Completed Penn State Security and Risk Analysis Certificate SRA Completed Penn State National Security Agency Certificate Program NSA Completed Academic Honors \u0026amp; Recognition # Honor / Recognition Detail Status Graduated Cum Laude Penn State University · B.S. Cybersecurity Analytics \u0026 Operations · GPA 3.88 Completed The Honor Society of Phi Kappa Phi Academic honor society membership Member Alpha Sigma Lambda Honor Society Academic honor society membership Member SANS NetWars CTF representing Penn State 14th nationwide placement Completed Experience Summary # ServiceNow SecOps Consultant / Cybersecurity Consultant # Supported client-facing ServiceNow SecOps and Vulnerability Response implementation work.\nRelevant work included requirements workshops, functional requirements, workflow documentation, user story tracking, RAID tracking, UAT support, training support, status meetings, and production go-live support.\nClient-Facing\nVulnerability Response Workflow # Worked with Vulnerability Response concepts involving vulnerable item ownership, assignment groups, remediation workflow, triage, validation, exception handling, and closure.\nVR Workflow\nSIEM / Cloud Security Exposure # Contributed to Azure and Microsoft Sentinel-related client work, gaining exposure to cloud security and SIEM processes.\nCloud + SIEM\nTechnical Communication # Created and supported documentation such as functional requirements, process flows, training materials, user stories, RAID items, and client-facing updates.\nDocumentation\nProfessional Experience Evidence # IST 495: Penn State College of IST Network Security Lab Development Internship # Academic internship with Penn State College of IST focused on networking lab modernization, technical research, lab validation, documentation, rubrics, teamwork, and supervisor-facing updates.\nInternship Networking sudoRunner Portfolio Website # This site is also a live project: Hugo, Cloudflare Pages, DNS, email routing, custom styling, mobile HCI fixes, favicon branding, guided review paths, and security-conscious publishing.\nLive Project HCI Selected Portfolio Evidence # These are the projects I would point to first in an interview. The full gallery is on the Projects page.\nEvidence What it shows Area ServiceNow SecOps Lab Hub Vulnerability Response workflow thinking: vulnerable item triage, ownership, remediation, validation, exceptions, and closure. Primary Focus CYBER 440: Cybersecurity Capstone Incident Response \u0026 Forensics A full incident response story using phishing, malware activity, forensic images, memory artifacts, logs, impact assessment, and remediation planning. Capstone CYBER 366: Malware Analytics \u0026 Reverse Engineering Static analysis, dynamic analysis, unpacking, FLOSS, PE review, ProcMon, RegShot, IDA Pro, Ghidra, Binary Ninja, and anti-debugging awareness. Malware IST 454: Computer \u0026 Cyber Forensics Forensic image creation, image mounting, hash verification, registry analysis, data carving, deleted file recovery, and AI/IoT forensics research. Forensics IST 456: Security \u0026 Risk Management SIEM-style investigation, ransomware, compromised credentials, data exfiltration, policy analysis, ISO 27000 concepts, compliance, and contingency planning. Risk / GRC IST 331: User-Centered Design User research, Figma prototypes, usability testing, workflow design, and iterative redesign. This supports the HCI direction of the portfolio. HCI Skills Snapshot # Area Representative Skills Evidence ServiceNow SecOps Vulnerability Response, vulnerable item workflow, triage, assignment ownership, remediation tracking, validation, closure, user stories, UAT, and training support. SecOps Lab Hub Incident Response / Forensics Incident timeline development, forensic image review, registry analysis, data carving, memory artifacts, log review, evidence handling, and remediation planning. CYBER 440 / IST 454 Malware Analysis Static analysis, dynamic analysis, strings/FLOSS, PEiD, UPX, ProcMon, RegShot, IDA Pro, Ghidra, Binary Ninja concepts, and anti-debugging awareness. CYBER 366 Risk / GRC Security risk management, cyber law, privacy, decision theory, analytic confidence, source credibility, incident planning, and compliance-aware reporting. IST 456 / SRA 311 OT/ICS Security SCADA/PLC concepts, cyber-physical risk, operational impact, availability, application-level disruption, and recovery validation. IST 451 Software / HCI Foundations Java, OOP, data structures, MVC, persistence, testing, usability testing, Figma prototyping, workflow design, web design, and static-site development. IST 240 / 242 / 261 / 311 / 331 Best-Fit Roles # ServiceNow SecOps Consultant # Best aligned with Vulnerability Response, SecOps workflow, requirements gathering, user stories, UAT, training support, and implementation communication.\nPrimary Fit\nCybersecurity Analyst # Aligned with security operations, incident response, malware analysis foundations, packet analysis, SIEM exposure, endpoint behavior review, and reporting.\nStrong Fit\nVulnerability Management Analyst # Aligned with vulnerable item triage, remediation ownership, risk review, assignment routing, exception handling, validation, and closure.\nStrong Fit\nOT/ICS Security Analyst # A developing specialty interest supported by OT/ICS academic exposure, cyber-physical risk thinking, availability concerns, and industrial security learning.\nDeveloping Specialty\nContact # For professional opportunities, portfolio review, or relevant technical conversations:\nContact Me Projects Review Paths ","externalUrl":null,"permalink":"/resume/","section":"Resume","summary":"","title":"Resume","type":"resume"},{"content":"Review Paths\nDo not try to read everything in one pass.\nThis page is meant to help different reviewers get to the right evidence quickly. A recruiter should not have to dig through every lab. A technical reviewer should not have to guess which projects are strongest. A ServiceNow reviewer should not have to search for Vulnerability Response work.\nFastest path: Start with the resume, then review the ServiceNow SecOps Lab Hub, CYBER 440 capstone, CYBER 366 malware labs, and the project gallery.\n60-Second Path # 1 Resume # Start with the public resume for the quick professional overview: education, credentials, experience, and role alignment.\nReview Resume\nStart\n2 ServiceNow SecOps # Review my strongest career-aligned section: Vulnerability Response workflow, ownership, remediation, validation, exceptions, and closure.\nReview ServiceNow SecOps\nPrimary Focus\n3 Capstone Evidence # Review the CYBER 440 capstone for the clearest incident response and forensic investigation story.\nReview CYBER 440 Capstone\nFlagship Project\n4 Malware and Forensics # Review CYBER 366 for malware analysis and IST 454 for dedicated forensics evidence.\nReview CYBER 366\nTechnical Depth\n5 Projects # Use the project gallery for the full course-coded evidence map.\nReview Projects\nProject Gallery\n6 Contact # Use the contact page after reviewing the core evidence.\nContact\nNext Step\nPaths by Reviewer Type # Recruiter / Hiring Manager # Use this path if you want the fastest hiring-oriented view.\nRecommended order:\nResume Opportunity Fit Projects Credentials Contact This path gives the fastest answer to: background, role fit, credentials, strongest evidence, and how to reach me.\nQuick Review Hiring Fit ServiceNow SecOps / Vulnerability Response Reviewer # Use this path if you care about SecOps workflow, vulnerable item ownership, remediation, and analyst process.\nRecommended order:\nServiceNow SecOps Lab Hub ServiceNow VR Triage Checklist IST 456: Security \u0026amp; Risk Management AI-Powered Vulnerability Ownership Recommender Capabilities This is the path I would point to first for ServiceNow SecOps conversations.\nPrimary Path ServiceNow Cybersecurity Analyst / SOC Reviewer # Use this path if you want investigation, logs, traffic, SIEM-style thinking, malware, and security operations evidence.\nRecommended order:\nCYBER 440: Cybersecurity Capstone CYBER 366: Malware Analytics IST 456: Enigma Glass Security \u0026amp; Risk Labs CYBER 362: Network Traffic Analysis \u0026amp; ML CYBER 262: Security Foundations This path shows the practical analyst side of the portfolio.\nAnalyst Path SOC-Relevant Incident Response / Forensics Reviewer # Use this path if you want evidence handling, imaging, logs, memory artifacts, timelines, and response planning.\nRecommended order:\nCYBER 440: Capstone Incident Response \u0026amp; Forensics IST 454: Computer \u0026amp; Cyber Forensics CYBER 342W: Incident Response, DR \u0026amp; BC Planning IST 451: Malware-Based Attack Investigation SRA 221: Information Security Foundations This path separates hands-on investigation from planning and response structure.\nIR / Forensics Evidence Handling Malware Analysis / Reverse Engineering Reviewer # Use this path if you want static analysis, dynamic analysis, reverse-engineering tools, suspicious processes, and malware behavior.\nRecommended order:\nCYBER 366: Malware Analytics \u0026amp; Reverse Engineering IST 451: Malware-Based Attack Investigation Lab CYBER 440: Capstone Incident Response \u0026amp; Forensics IST 454: Computer \u0026amp; Cyber Forensics CYBER 262: Security Foundations This path is the best fit for malware-analysis conversations.\nMalware Reverse Engineering GRC / Risk / Privacy Reviewer # Use this path if you want the governance and risk side of the portfolio.\nRecommended order:\nIST 456: Security \u0026amp; Risk Management IST 432: Cyber Law, Privacy \u0026amp; GRC SRA 311: Risk Analysis in a Security Context SRA 231: Decision Theory \u0026amp; Analysis CYBER 342W: Incident Response, DR \u0026amp; BC Planning This path shows the risk, policy, decision-making, and communication layer behind the technical work.\nGRC Risk Analysis OT/ICS Security Reviewer # Use this path if you want cyber-physical risk, operational impact, SCADA/PLC concepts, and availability-focused security thinking.\nRecommended order:\nOT/ICS Security IST 451: ICS/IT-OT Application-Level DoS Attack Lab CYBER 440: Capstone Incident Response \u0026amp; Forensics IST 495: Network Lab Development Internship IST 402: Cloud Virtualization, Containers \u0026amp; SECaaS This path is about availability, operations, and security where systems affect the real world.\nOT/ICS Specialty Interest Cloud Security / Infrastructure Reviewer # Use this path if you want infrastructure, containers, private cloud, zero trust concepts, and networking.\nRecommended order:\nIST 402: Cloud Virtualization, Containers \u0026amp; SECaaS Architecture IST 495: Network Lab Development Internship SRA 221: Information Security Foundations CYBER 362: Network Traffic Analysis \u0026amp; ML Capabilities This path shows the infrastructure foundation behind security operations.\nCloud Infrastructure HCI / Workflow / Software Reviewer # Use this path if you care about usability, workflow design, software foundations, and how I think about interfaces.\nRecommended order:\nIST 331: User-Centered Design \u0026amp; Booking.com Redesign sudoRunner Portfolio Website IST 261: Productivity Assistant Application Design Studio IST 311: Java Data Structures \u0026amp; Software Engineering Foundations IST 250: Uphill Struggle Bicycles Web Design Project This path explains why the portfolio emphasizes navigation, review flow, and usability.\nHCI Software Best Pages by Topic # Topic Start With Why ServiceNow SecOps ServiceNow SecOps Lab Hub Primary Incident Response CYBER 440 Capstone Flagship Forensics IST 454 Computer \u0026 Cyber Forensics Forensics Malware Analysis CYBER 366 Malware Analytics Malware GRC / Risk IST 456 Security \u0026 Risk Management Risk Cyber Law / Privacy IST 432 Cyber Law, Privacy \u0026 GRC Privacy Cloud Security IST 402 Cloud Virtualization \u0026 SECaaS Cloud OT/ICS IST 451 ICS/IT-OT DoS Lab OT/ICS HCI / Usability IST 331 User-Centered Design HCI Professional Internship IST 495 Network Lab Development Internship Internship What I Would Not Read First # Some pages are included because they show progression, not because they are headline evidence. IST 240, IST 242, IST 250, SRA 221, and SRA 231 are useful supporting pages, but I would not start there unless you are specifically reviewing software foundations, web design, or decision-analysis background.\nQuick Actions # Resume Projects Capabilities Contact ","externalUrl":null,"permalink":"/review-paths/","section":"","summary":"","title":"Review Paths","type":"page"},{"content":"Security-Conscious Publishing\nThis page explains how sudoRunner is designed as a public cybersecurity portfolio while limiting unnecessary exposure of personal, academic, client, or sensitive information.\nPrinciple: This site is meant to show proof of work, technical depth, and professional thinking without publishing raw submissions, private identifiers, confidential data, or unnecessary sensitive details.\nPrivacy-Conscious Public Resume # The public resume available on this site is intentionally different from a direct job-application resume.\nIt uses:\nVlad K. as the public display name a professional contact alias broad location only no private phone number no private personal email address Public Resume Privacy-Aware Professional Contact Alias # This site uses:\ncontact@sudorunner.org\nas the public-facing contact email.\nThe address is configured as a professional forwarding alias through Cloudflare Email Routing. This allows professional contacts to reach me without requiring my private inbox address to be posted directly on the website.\nProfessional Alias Cloudflare Email Routing Redacted Project Publishing # Projects and labs are rewritten into sanitized case studies.\nRaw academic files, full solution files, sensitive screenshots, lab credentials, private identifiers, and unnecessary procedural details are not published.\nBefore publishing project content, I review for:\nfull names of classmates, professors, or unrelated individuals private email addresses phone numbers student IDs raw screenshots with identifying details credentials, secrets, tokens, or keys lab-specific IP addresses when not needed full exploit instructions or unnecessary offensive detail client names or proprietary implementation details anything that could violate academic, employer, or client confidentiality Redacted Portfolio-Safe Security Contact Standard # Site Metadata Files # This site includes standard public metadata files:\nrobots.txt humans.txt security.txt These files support search engine discovery, basic site transparency, and standard security contact discovery.\nSite Metadata Configured This site includes a public security.txt file at:\n/.well-known/security.txt\nThis provides a standard location for security contact and policy information related to the site.\nsecurity.txt Configured Security Headers # This site includes basic security headers through Cloudflare Pages static header configuration.\nConfigured headers include:\nX-Frame-Options X-Content-Type-Options Referrer-Policy Permissions-Policy Cross-Origin-Opener-Policy These headers help reduce common browser-side risks such as clickjacking, unnecessary permission exposure, MIME sniffing, and excessive referrer leakage.\nSecurity Headers Configured Static Site Deployment # sudoRunner is deployed as a static website using Hugo, GitHub, and Cloudflare Pages.\nThis approach has several security and maintenance advantages:\nno traditional database exposed to the public no WordPress-style admin panel no server-side login portal version-controlled content changes automated deployment through Git simple rollback through repository history fast static hosting through Cloudflare Static Site Cloudflare Pages Content Boundaries # This website does not publish:\nclient data private employer documents internal implementation screenshots raw academic submissions private contact details credentials or secrets full exploit walkthroughs sensitive infrastructure details The goal is to demonstrate cybersecurity knowledge, project experience, and technical communication while respecting privacy, confidentiality, and professional boundaries.\nRelated Pages # Projects Resume Contact sudoRunner Project ","externalUrl":null,"permalink":"/security-privacy/","section":"","summary":"","title":"Security \u0026 Privacy","type":"page"},{"content":"","externalUrl":null,"permalink":"/series/","section":"Series","summary":"","title":"Series","type":"series"},{"content":"Start Here\nI built this site so a reviewer does not have to guess where to click.\nA resume gives the overview, but the portfolio shows the work behind it: ServiceNow SecOps, Vulnerability Response, incident response, malware analysis, forensics, GRC, OT/ICS security, cloud security, HCI, and software foundations.\nBest first path: Resume → ServiceNow SecOps → CYBER 440 Capstone → Projects → Contact.\nBegin with Resume Choose a Review Path View Projects Fast Review Path # 1 Resume # Start here for the quick professional picture: education, credentials, experience, and best-fit roles.\nReview Resume\nStart\n2 ServiceNow SecOps # This is the most career-aligned part of the portfolio. It shows how I think through Vulnerability Response workflow, ownership, remediation, validation, and closure.\nReview ServiceNow SecOps\nPrimary Focus\n3 CYBER 440 Capstone # This is one of the strongest academic projects. It connects phishing, malware activity, forensic images, memory artifacts, logs, impact, and remediation into one incident response story.\nReview Capstone\nFlagship Evidence\n4 Projects # Use the project gallery to see the full course-coded evidence map across malware analysis, forensics, GRC, risk, cloud, HCI, software, OT/ICS, and internship work.\nReview Projects\nEvidence Map\n5 Capabilities # Use this page to connect skills to evidence. It is the quickest way to see what I can credibly discuss in an interview.\nReview Capabilities\nSkill Evidence\n6 Contact # Reach out after reviewing the relevant evidence.\nContact\nNext Step\nWhat to Read First # For ServiceNow SecOps # Start with the ServiceNow SecOps Lab Hub and ServiceNow VR Triage Checklist.\nThese pages are closest to the work I want to keep building on professionally.\nPrimary Focus Vulnerability Response For Cybersecurity Analyst Roles # Start with CYBER 440, CYBER 366, IST 454, and IST 456.\nThat path shows investigation, malware, forensics, SIEM-style review, and risk-based reporting.\nAnalyst Path IR / Forensics For GRC and Risk # Start with IST 456, IST 432, SRA 311, and CYBER 342W.\nThat path shows risk thinking, cyber law, privacy, incident planning, and security management.\nRisk Path GRC For OT/ICS Security # Start with the OT/ICS Security section and the IST 451 ICS/IT-OT DoS Lab.\nThis is a developing specialty interest, focused on cyber-physical risk, operational disruption, availability, and recovery validation.\nSpecialty Interest OT/ICS For HCI and Workflow Design # Start with IST 331 User-Centered Design and the sudoRunner Portfolio Website.\nThese explain why I care so much about usability, clear navigation, and workflow design.\nHCI Workflow Design For Software and Application Foundations # Start with IST 261, IST 311, IST 242, and IST 240.\nThese are supporting pages. They show the programming foundation behind the security work.\nSoftware Foundation Java / OOP The Short Version # Question Best Page Why What is the main career focus? ServiceNow SecOps Lab Hub Primary What is the strongest academic project? CYBER 440 Capstone Flagship Where is malware analysis shown? CYBER 366 Malware Analytics Malware Where is forensics shown? IST 454 Computer \u0026 Cyber Forensics Forensics Where is GRC/risk shown? IST 456 Security \u0026 Risk Management Risk Where is professional experience shown? IST 495 Network Lab Development Internship Internship What Not to Read First # Some pages show progression rather than headline evidence. IST 240, IST 242, IST 250, SRA 221, and SRA 231 are useful supporting pages, but they are not where I would send a reviewer first unless they specifically ask about software foundations, early web design, information security basics, or decision theory.\nNext Step # Start with Resume View Projects View Capabilities Contact ","externalUrl":null,"permalink":"/start-here/","section":"","summary":"","title":"Start Here","type":"page"}]