diff --git a/CP-01-security-awareness-essentials/README.md b/CP-01-security-awareness-essentials/README.md new file mode 100644 index 0000000..b9fa6e3 --- /dev/null +++ b/CP-01-security-awareness-essentials/README.md @@ -0,0 +1,549 @@ + + +# Security Awareness Essentials + +Welcome to **Security Awareness Essentials** — the foundational security training for every CivicActions team member. + +This course covers the core behaviors and responsibilities you need to protect CivicActions systems, data, and clients. Whether its keeping your laptop secure, handling data correctly, or reporting something suspicious — this training has you covered. + +**Who takes this?** Everyone — full-time staff, contractors, interns, and any third party with access to CivicActions systems. + +**How long?** About 30–40 minutes. + +**When?** Within 30 days of onboarding, then annually, and whenever there's a major policy change. + +--- + +Let's get started! + +## Module A — Your Devices and Workspace + +Your laptop and workspace are the front line of security. This module covers what you need to know about your CivicActions-managed laptop, the software you install, and how to stay secure — whether you're at home, at a coffee shop, or on the road. + +### Managed Devices + +CivicActions issues employees a [**managed laptop**](https://civicactions.atlassian.net/wiki/spaces/ITSM/pages/161087491/CivicActions+Laptops). This laptop comes pre-configured with: + +- **Full-disk encryption** — so your data stays protected if the device is lost or stolen +- **Scanning software** that checks for any security issues or viruses +- **Firewall** enabled by default +- **Auto-lock** — your screen locks automatically after a short idle period +- **Automatic patching** — your OS and security software stay up to date + +> **Important:** You must use your CivicActions laptop for all work involving Internal, Confidential, or client data. Personal (BYOD) mobile devices can only be used for MFA prompts and communication apps + +> **Example:** Your CivicActions Laptop comes with the Iru Mobile Device Management (MDM) system that manages FileVault encryption, security scanning, firewall, and patching out of the box. You don't need to configure any of this yourself — IT handles it before your laptop ships to you. + +> **Tip:** It's smart to keep your personal devices protected with a strong password, an idle screen lock and attention to security updates. Also, use multi-factor authentication (MFA) whereever possible and stay alert to avoid phishing scams. More tips [here](https://ssd.eff.org/). + +### Software Rules + +Not all software is safe to use. CivicActions maintains an [**Approved Software Catalog**](https://docs.google.com/spreadsheets/d/1yy7xSeTmTBCCaG5B-oJI3dwMN3r7tFPQ-lw79zOAdFE/edit?gid=852934818#gid=852934818) and a [**Prohibited Hardware and Software**](https://guidebook.civicactions.com/en/latest/company-policies/prohibited-hardware-and-software/) list. + +- Only install software from the Approved Catalog +- If you need something new, submit a request through the [access and authorization workflow](https://civicactions.atlassian.net/wiki/spaces/ITSM/pages/1026719753/Approval+Process+for+Software+and+Services) +- Iru will block software that isn't approved + +Think of it this way: if it's not on the approved list, don't install it. + +> **What's approved?** Tools like Google Drive, Slack, Zoom, 1Password, Docker and GitHub Desktop are all in the catalog. What's prohibited? Huawei/ZTE devices, TikTok, Kaspersky, consumer "free VPN" apps, and ad-ware — Iru will block these automatically if you try to install them. + +### Home Workspace Security + +Working from home? Here are the basics: + +- Position your screen so others can't see it (especially during video calls) +- Don't print anything that is Confidential or Restricted unless you have a cross-cut shredder and **shred it the same day** +- Protect your laptop from spills, heat, pets, and other environmental hazards +- If possible, use a **surge-protected outlet** for your laptop and monitor + +> **Example:** You're on a Zoom call discussing a client's infrastructure when a friend stops by. Close your laptop lid or lock the screen before answering the door — and don't forget to close any admin consoles, CI/CD dashboards, or cloud management tabs you had open in the background. + +### Networks and Wi-Fi + +Your network connection matters just as much as your laptop. + +- Use **WPA2 or WPA3** encrypted Wi-Fi, or a wired Ethernet connection + - If secure Wi-Fi isn't available, use your phone's **personal hotspot** +- **No VPNs** unless required by the company or a client +- **Change the default admin password** on your home router (many people skip this) and keep the firmware updated +- **Never click through TLS/SSL warnings** — they exist for a reason + +> **Example:** You're at a coffee shop between meetings. The shop has open Wi-Fi — no password required. Skip it. Tether to your phone's hotspot instead. It takes 30 seconds and keeps your connection encrypted. + +### Travel and Public Locations + +On the go? Extra caution is needed: + +- Keep your laptop **physically with you** at all times + - Of course, leaving it lid-closed, in a locked hotel room to go out to dinner is fine +- **Lock your screen** every time you step away, even for a minute +- Avoid displaying sensitive info where others can see your screen +- Use encrypted Wi-Fi or your personal hotspot — **never connect to open public Wi-Fi** +- Avoid printing sensitive documents while traveling + +> **Example:** You're at an airport waiting for a flight and need to review a client proposal. Find a seat where nobody can read over your shoulder, and use your phone's hotspot instead of the airport Wi-Fi. When you get up to grab coffee, lock the screen — don't just close the lid, since it might not trigger a lock immediately. + +### Keeping Your Laptop Secure + +CivicActions' Iru Mobile Device Management (MDM) system enforces minimum **OS and patch levels**. If your laptop falls behind you'll get a reminder to allow the update to occur. If you don't, your laptop may **automatically update** at a time that could be disruptive to your work. + +Don't ignore update prompts — they keep you and the organization safe. + +> **Example:** Iru detects your laptop is two patch versions behind. You get a notification and if you don't update within the grace period, Iru can restrict your access to CivicActions systems until you're current. A quick restart is a lot easier than being locked out mid-sprint. + +### Module A Quiz + +Your CivicActions laptop prompts you to install a system update. You're in the middle of a deadline. What should you do? + +- [( )] Dismiss the update permanently to avoid interruption +- [(X)] Install the update at the next reasonable opportunity — don't postpone indefinitely +- [( )] Disable the Iru Mobile Device Management system so updates stop appearing +- [( )] Uninstall the update software +*** + +**Correct!** System updates patch security vulnerabilities. You don't need to drop everything, but you should install them as soon as reasonably possible. Never disable Iru or dismiss updates permanently — your laptop could be blocked for non-compliance. + +*** + +## Module B — Your Identity and Access + +Your digital identity is how CivicActions verifies that *you* are *you*. This module covers your CivicActions account, multi-factor authentication (MFA), passwords, and the rules around who gets access to what. + +Links to the full [**Identification Policy**](https://civicactions.atlassian.net/wiki/spaces/MGPOL/pages/709951516/Identification+Policy) and [**Access Control Policy**](https://civicactions.atlassian.net/wiki/spaces/MGPOL/pages/744947714/Access+Control+Policy) + +### Your CivicActions Identity + +- Your **@civicactions.com account** is your primary identity for all work systems +- **Never use personal accounts** (like a personal Gmail) for CivicActions work +- CivicActions uses a `firstname.lastname@civicactions.com` naming convention — IT sets this up when you onboard. If your name matches someone else's, IT adds a middle initial or variation. + +> **Example:** When you join, PeopleOps verifies your identity through Rippling. IT then creates your Google Workspace account, assigns you to the right groups and Slack channels, issues your YubiKey and orders your CivicActions laptop — all before your first day. + +### SSO and MFA + +**Single Sign-On (SSO)** lets you log in once and access multiple work systems. Use SSO wherever it's available. + +> **In practice:** Your Google Workspace login is the front door. When you sign in there, SSO automatically connects you to Slack, Zoom, Jira, Confluence, GitLab, and other CivicActions systems — no separate passwords needed. + +**Multi-Factor Authentication (MFA)** adds a second layer of proof that you are who you say you are. + +- Enroll your [**YubiKey as a Passkey**](https://civicactions.atlassian.net/wiki/spaces/ITSM/pages/732856328/Yubikey+Passkey+Setup+Process) for quick authentication to CivicActions Google Workspace + +> **Why a hardware key?** They are phishing resistant and are preferred over SMS codes or authenticator apps. Even if someone tricks you into entering your password on a fake site, they can't intercept a hardware key. + +If you lose your YubiKey, report it immediately to security@civicactions.com - IT will disable the lost key, verify your identity, and send you a replacement. If you are locked out of your laptop or Google Account, follow the procedure for [Internal Technical Support](https://guidebook.civicactions.com/en/latest/common-practices-tools/software-and-support/#emergency-locked-out) in the Guidebook + +> **Tip:** Consider buying a second YubiKey and keep one on your keychain and store the backup in a secure spot at home. + +### Password Standards + +Strong passwords are your first line of defense: + +- **20 characters minimum** for human accounts +- **Memorize** your primary password and use a **password manager** for everything else +- **Never reuse passwords** across different services — if one gets compromised, they all do + +> **Example:** Use your password manager to generate and store unique, strong passwords/passphrases for any service that doesn't support Google SSO. Your Google Workspace passphrase is the one you memorize - make it long and unique - four or five words that only mean something to you is recommended. + +> **Tip:** 1Password, BitWarden, LastPass and Proton Pass are some of the best known password managers. + +### Access Requests + +Need access to a new system or project? + +1. Submit a request through the **defined access request process** — file a ticket or use a Rippling workflow with the system name, your justification, how long you need it, and which project it's for +2. Access is granted based on **least privilege** — you get only what you need +3. If your role changes or you leave, **notify IT promptly** so access can be adjusted + +> **Note:** Access to client systems is managed separately by the client project managers and security team. + +### Project Boundary Awareness + +Your access is **scoped to your assigned projects**. This means: + +- Don't access systems or data outside your current project +- When you transition between projects, your access is **automatically reviewed** +- If you think you need broader access, request it through the proper channel + +> **Example:** You finish a project for Client A and move to Client B. Your manager triggers a rights review — your Client A GitLab access and Shared Drive permissions are removed, and new access for Client B is set up through a fresh ticket. This keeps client data cleanly separated. + +### Module B Quiz + +You're setting up MFA for your CivicActions account. Which method is the preferred primary factor? + +- [( )] SMS text message code +- [( )] Voice call one-time password +- [(X)] FIDO2/WebAuthn hardware security key (e.g., YubiKey) +- [( )] Email-based one-time password +*** + +**That's right!** FIDO2/WebAuthn hardware keys are phishing-resistant — they physically verify the site you're logging into, so attackers can't intercept them. SMS and email codes can be intercepted or phished, which is why hardware keys are the CivicActions standard. + +*** + +## Module C — Data Handling and Classification + +Not all data is created equal. CivicActions classifies data into levels so everyone knows how to handle, store, and share it properly. This module teaches you the classification system and the rules that go with each level. + +Here's a link to the full [**Data Security and Handling Policy**](https://civicactions.atlassian.net/wiki/spaces/MGPOL/pages/710213662/Data+Security+and+Handling+Policy) + +### Four Classification Levels + +CivicActions uses four levels of data classification: + +| Level | What it means | If mishandled | +|-------|---------------|---------------| +| **Public** | Approved for release — website content, published marketing materials, open-source code. Anyone in the organization can access and share this data. | Minimal risk. | +| **Internal** | Non-sensitive internal procedures — meeting notes, project timelines, internal process documents. Should not be shared outside the organization. | Minor operational disruptions, but no severe compliance consequences. | +| **Confidential** | High-stakes data — client contracts, technical drawings, other Federal Contract Information (FCI), Controlled Unclassified Information (CUI). Access limited to those with a legitimate business need. | Could jeopardize contract eligibility or lead to regulatory penalties. | +| **Restricted** | The most sensitive data — payroll records, login credentials, Social Security Numbers, Personal Health Information (PHI). Access strictly controlled and monitored. | Severe harm, including legal action or significant financial loss. | + +> **Default rule:** All data is treated as **Internal** until someone explicitly classifies it otherwise. + +### Handling Rules by Sensitivity Level + +Each sensitivty classification level has specific rules for sharing, storage, and transmission: + +- **Public:** No special handling needed +- **Internal:** Keep within CivicActions systems; don't post externally +- **Confidential/Restricted:** Must be **encrypted in transit and at rest**; access on a need-to-know basis only + - **Controlled Unclassified Information (CUI)** has additional handling controls over other Confidential data + +When in doubt, treat data as Confidential and ask your manager or IT. + +> **Example:** You're writing a blog post about a project approach. The blog content is Public, but the client name and contract details behind it are Confidential. Before publishing, make sure the post only references what the client has approved for public release. + +### Approved Storage + +Where you store data matters: + +- **Use only CivicActions-managed systems:** Google Workspace, approved SaaS platforms, and managed endpoints +- **Never store work data on personal cloud accounts** (personal Google Drive, iCloud, Dropbox, etc.) + +If it's work data, it belongs on work systems — period. + +> **General rule:** All work related information should be stored in the cloud in the appropriate CivicActions Google Shared Drive or in GitHub/GitLab. + +> **Example:** You're drafting a proposal and want to save it locally "just in case." Don't — sync it to your [**CivicActions Google Drive**](https://civicactions.atlassian.net/wiki/spaces/ITSM/pages/620462113/Google+Drive+User+Guide) instead. That way it's backed up, access-controlled, and covered by DLP monitoring. If something happens to your laptop, the file is still safe in the cloud. + +> **Tip:** Learn to spot labeled files in Google Workspace — look for banners, filename tags (like `[CUI]` or `[Confidential]`), or workspace labels on documents and folders. If a file contains sensitive information but doesn't have any of these markers, flag it to your manager or IT so it can be properly labeled before anyone shares it further. + +### Sharing Safely + +Sharing data the wrong way is one of the most common security mistakes: + +- **Google Docs:** Share by **individual email address**, not "anyone with the link" +- **Confidential files sent externally:** Use a **password-protected AES-256 archive** with a **20+ character passphrase** + - **Send the passphrase through a separate channel** (e.g., share the file by email, send the password via Slack) +- **Never use email for Confidential or Restricted data** — use Google Drive sharing instead +- **Slack is for Public, Internal and some Confidential information** — never paste or upload CUI or Restricted data (including system vulnerability scans and login credentials) in Slack channels or DMs + +> **Example:** A partner organization needs a Confidential deliverable but doesn't have access to your Google Drive. Create a password-protected ZIP archive with a 20+ character passphrase, email the archive, and then send the passphrase via Slack DM — never in the same email. + +### Removable Media and Printing + +The general rule: **avoid both** whenever possible. + +- If you must print something, **secure it and shred it the same day** +- Do not use removable media - this includes USB drives - without express permission from CISO or CTO. + +### DLP and Monitoring + +CivicActions uses **Data Loss Prevention (DLP)** tools that may flag unusual data transfers. Here's what to know: + +- Monitoring exists to **protect the organization**, not to watch over individuals +- If a DLP tool flags something you did for a legitimate reason, just respond to the follow-up request — it's not a disciplinary action + +> **Example:** Google Workspace DLP rules scan for patterns like Social Security numbers and the keyword "CUI." If you share a Google Doc containing a SSN and the sharing settings are too broad, DLP may automatically block it and notify the security team. Just explain the context when asked — it's a safety net, not a gotcha. + +### Module C Quiz + +You need to share a Google Doc with Internal project data with a colleague. Which sharing method is correct? + +- [( )] Set the link to "anyone with the link can view" +- [(X)] Share directly with your colleague's CivicActions email address +- [( )] Email the document to your colleague's personal Gmail +- [( )] Post the link in a public Slack channel +*** + +**Exactly!** Always share Google Docs by individual CivicActions email address. "Anyone with the link" makes the document accessible to anyone who gets that link — intentionally or accidentally. + +*** + +## Module D — Acceptable Use and AI + +CivicActions systems are tools for getting work done. This module covers the rules around how you use those tools — including the rapidly evolving area of AI. + +Links to the full [**Acceptable Use Policy**](https://civicactions.atlassian.net/wiki/spaces/MGPOL/pages/755957762/Acceptable+Use+Policy) and [**AI Usage Policy**](https://civicactions.atlassian.net/wiki/spaces/MGPOL/pages/582418435/AI+Usage+Policy) + +### Core Principles + +- CivicActions systems are for **authorized business use** +- **Limited personal use is OK** — as long as it doesn't interfere with work, consume significant resources, or violate any policy +- When in doubt, ask + +> **Example:** Checking personal email or reading the news during a break is fine. Storing personal photos on your CivicActions Google Drive or running a side business from your managed laptop is not. + +### Prohibited Activities + +Some things are never OK: + +- **Circumventing security controls** (disabling firewalls, VPN bypasses, etc.) +- **Unauthorized data exfiltration** — taking work data out of approved systems +- **Using non-approved tools** for work data +- **Sharing your credentials** with anyone, for any reason + +> **Example:** A colleague on a tight deadline asks for your GitLab credentials to push a fix while you're away. The answer is always no — even with good intentions. They should request their own access through the proper workflow. + +### AI Tools — General Rules + +AI can be a powerful productivity tool, but it comes with real risks. Here are the ground rules: + +1. **Use only [CivicActions-approved AI tools](https://civicactions.atlassian.net/wiki/spaces/MGPOL/pages/582418435/AI+Usage+Policy)** with IT-managed accounts +2. **Never input sensitive, confidential, or client-internal data** into any AI tool — even approved ones +3. **Human oversight is required** for all AI-generated output + - While it may have been generated by AI, **you are responsible** for shared output +4. **Clearly label AI-generated or AI-assisted content** internally +5. **Peer-review AI content** before sharing it externally + +> **Think of it this way:** Anything you type into an AI tool could end up in a training dataset. Would you be comfortable seeing your input in a news article? If not, don't enter it. + +### Approved AI Tool Categories + +CivicActions has approved specific AI tools for different purposes: + +- **General purpose:** Slack Chatbot, Gemini, ChatGPT for Teams +- **Coding:** GitHub Copilot +- **Specialist:** Grammarly, Paxton AI +- **Service integrations:** Zoom AI, Mural, Confluence/Jira, Greenhouse, Figma + +> **Note:** ChatGPT's Atlas browser feature is **not approved**. Stick to the approved configurations. + +### New AI Tools + +Want to use an AI tool that isn't on the approved list? + +- You need **CTO approval** before using it +- On client projects, you also need **client approval** +- Every new tool goes through a **risk assessment** based on the NIST AI Risk Management Framework + +> **Example:** You hear about a new AI transcription tool that could save time on meeting notes. Before signing up, check with the CTO — even a free trial counts. If it touches CivicActions data, it needs vetting first. + +### Module D Quiz + +A colleague asks you to paste a client's internal financial data into ChatGPT to summarize it. What should you do? + +- [( )] Go ahead — ChatGPT is on the approved tools list +- [(X)] Refuse — never input sensitive, confidential, or client-internal data into any AI tool, even approved ones +- [( )] Ask the client for permission first, then proceed +- [( )] Use Gemini instead since it's a Google product +*** + +**Good call!** Even approved AI tools must never receive sensitive, confidential, or client-internal data. The "approved" status means the tool itself is OK to use for general work — it doesn't mean all data is safe to put into it. Data classification rules always apply. + +*** + +## Module E — Recognizing and Reporting Incidents + +Security incidents happen — even to careful people. What matters most is how quickly you respond. This module teaches you what to look for, how to report it, and what happens next. + +### See Something, Say Something + +If you observe **anything** that might be a security incident, outage, or suspicious activity — **raise a flag immediately**. Don't wait until you're sure. + +**How to report:** + +- Post in **Slack #general** +- **DM an IT team member** directly +- **DM your manager** +- Email **security@civicactions.com** + +Use whichever channel is fastest. Speed matters more than formality. + +> **Examples of things to report:** A phishing email, a lost laptop, an unfamiliar login alert, a SaaS app behaving strangely, a colleague who seems to have access they shouldn't, a physical security concern at a co-working space. + +### Blame-Free Reporting + +CivicActions has a **blame-free reporting culture**: + +- Good-faith reporting will **never result in retaliation** +- **Speed matters more than certainty** — it's better to report something that turns out to be nothing than to stay silent about something real +- We learn more from honest reports than from silence + +> **Example:** You accidentally sent a Google Doc with Internal data to the wrong email address. Report it right away — DM an IT team member or email security@civicactions.com. This kind of honest report helps the team contain the issue quickly. Nobody gets in trouble for an honest mistake reported fast. + +### Lost or Stolen Devices + +If a device is lost or stolen, report it **immediately** through the incident channels. Include: + +- **What** device (laptop, phone, etc.) +- **When** it went missing +- **Where** you last had it +- **What data** might be exposed + +This applies to **both CivicActions laptops and personal devices** that have authenticated to CivicActions systems (like a phone used for MFA). + +> **Example:** You left your CivicActions MacBook in a rideshare. DM an IT team member on Slack right away with: "Lost my laptop in a Lyft at 3 PM, last had it at the airport, had access to Client B's Shared Drive." IT can trigger a remote wipe through Iru immediately — FileVault encryption means the data is already protected, but the wipe makes sure. + +### Incident Confidentiality + +When an incident is under investigation: + +- Treat incident details on a **need-to-know basis** +- **Don't share details** outside the designated channels (Slack incident thread, email to security team, etc.) + +> **Example:** You hear that a SaaS vendor CivicActions uses had a breach. Don't post about it in a public Slack channel or mention it to a client. Wait for the Incident Commander or Communications Officer to share approved updates through the proper channels. + +### Post-Incident Participation + +After an incident is resolved, you may be asked to participate in a **retrospective** (or "post-mortem"). These are learning sessions, not blame sessions: + +- Share what you observed honestly +- Focus on **what happened** and **how to prevent recurrence** +- Lessons learned feed back into policy and operations improvements + +### Module E Quiz + +You receive a suspicious email with an attachment claiming to be an invoice. What is the correct first step? + +- [( )] Open the attachment to check if it looks legitimate +- [( )] Forward it to your personal email for safekeeping +- [(X)] Report it immediately to security@civicactions.com +- [( )] Delete it and forget about it +*** + +**Correct!** Never open suspicious attachments. Report the email immediately so the security team can analyze it and warn others if needed. Deleting it silently means the team can't investigate — and others might fall for the same phishing attempt. + +*** + +## Module F — Governance, Risk, and Compliance + +You don't need to be a compliance expert, but it helps to understand the big picture. This module gives you a quick overview of how CivicActions policies are organized, what frameworks they align to, and what you can do to support them. + +### Policy Structure + +CivicActions has a layered policy structure: + +- **[CivicActions Company-wide Policies](https://civicactions.atlassian.net/wiki/spaces/MGPOL/overview?homepageId=309068052)** is a Confluence page that contains all current policies +- Most of this training stems from the [**Information Security Policy**](https://civicactions.atlassian.net/wiki/spaces/MGPOL/pages/703725569/Information+Security+Policy) which delegates specifics to **subordinate policies**: Acceptable Use, Access Control, Incident Response, Data Security, and more +- All policies are accessible to you — [know where to find them](https://civicactions.atlassian.net/wiki/spaces/MGPOL/overview?homepageId=309068052) if you need them + +> **Example:** Wondering what the rules are for using USB drives? You'd look at the Data Security and Handling Policy. Not sure about your MFA requirements? Check the Identification Policy. The Information Security Policy is the table of contents — it points you to the right place. + +### Compliance Frameworks + +CivicActions aligns to several compliance frameworks: + +| Framework | What it covers | +|-----------|---------------| +| **CMMC L1/L2** | Federal contractor cybersecurity requirements (FAR/NIST 800-171) | +| **ISO 27001** | International information security management standard | +| **ISO 9001** | Quality management | +| **ITIL** | IT service management best practices | + +This training satisfies security awareness requirements for CMMC and ISO 27001. + +### Risk Awareness + +Understanding risk doesn't have to be complicated: + +- **CIA triad:** Confidentiality, Integrity, Availability — these are the three things we protect +- **3×3 risk scale:** Likelihood (Low/Medium/High) × Impact (Low/Medium/High) +- **Risk acceptance** must be explicit and approved by the right people — you can't just decide to accept a risk on your own + +> **Example:** You notice that a tool your team uses doesn't support SSO. You can't just decide "that's fine" and keep using it with a local password. A risk like that needs to be formally documented in the Jira Risk Register and approved by the appropriate authority — the CISO or CTO for higher risks, or an IT team member for lower ones. + +### Disaster Recovery Communications + +During a major outage, normal communication tools might be down. Here's the backup plan: + +1. **Primary:** Slack chat, Slack huddle, Zoom video +2. **Secondary:** Google Chat, Google Meet, telephone + +Clients and partners are notified only if the outage impacts deliverables. + +### Document Change Requests + +Want to suggest a change to a policy or controlled document? + +- Submit an [**internal IT support request**](https://civicactions.atlassian.net/wiki/spaces/ITSM/pages/607584257/Atlassian+Assist) +- Controlled Documents are **reviewed annually** +- Access to documents is managed via **security groups** + +> **Example:** You spot an outdated link in the Acceptable Use Policy. Create a ticket on the Compliance Jira board describing the change. The Document Controller reviews it, and if approved, a new minor version (e.g., 2.1 → 2.2) is published. You don't need to edit the document yourself. + +### Maintenance and Patching + +You don't need to manage these programs — but you should know they exist: + +- CivicActions IT manages [**configuration management**](https://civicactions.atlassian.net/wiki/spaces/MGPOL/pages/767983618/Configuration+Management+Policy), [**change enablement**](https://civicactions.atlassian.net/wiki/spaces/MGPOL/pages/768114689/Change+Enablement+Policy), [**vulnerability and patch management**](https://civicactions.atlassian.net/wiki/spaces/MGPOL/pages/768344065/Vulnerability+and+Patch+Management+Policy) +- Think of these as **guardrails, not gates** — they run in the background to keep everything secure +- Your part: install updates when prompted and report anything that seems off + +### Third-Party Awareness + +CivicActions works with outside vendors and partners. Here's what you should know: + +- **No supplier** may be procured or granted system access until due diligence is complete +- If you have concerns about a vendor's security practices, **report them to IT** + +> **Example:** A project lead wants to try a new design collaboration tool. Before signing up, it needs to go through supplier intake and Confidentiality, Integrity, Availability, and eXpense (CIAX) scoring for SaaS, SSO/MFA validation, data residency review. Even a free-tier tool that touches CivicActions data must be vetted first. + +### Module F Quiz + +During a major SaaS outage, Slack is unavailable. What is the next communication channel to use per the Disaster Recovery Plan? + +- [( )] Personal text messages +- [(X)] Zoom or Google Chat +- [( )] Twitter/X direct messages +- [( )] Wait until Slack comes back +*** + +**Right!** The DR communication hierarchy is: Primary (Slack/Zoom), Secondary (Google Chat/Meet or telephone). Knowing these backups means you can stay connected and coordinated even when the primary tools are down. + +*** + +## Bonus Quiz + +You've completed all six modules — nice work! Here's one final question that covers an important topic from the course. + +What is the **default classification level** for all CivicActions data that hasn't been explicitly classified? + +- [( )] Public +- [(X)] Internal +- [( )] Confidential +- [( )] Restricted +*** + +**Correct!** All data is treated as **Internal** by default until it is explicitly classified otherwise. This means you should handle any unclassified data as Internal — keep it within CivicActions systems and share it only with CivicActions team members. If you think data should be treated at a higher (or lower) level, work with your manager to get it properly classified. + +*** + +## Course Complete + +Congratulations — you've finished **Security Awareness Essentials**! + +Here's what you covered: + +1. **Devices and workspace** — managed laptops, approved software, home and travel security +2. **Identity and access** — SSO, MFA with hardware keys, passwords, least-privilege access +3. **Data handling** — classification levels, approved storage, safe sharing +4. **Acceptable use and AI** — approved tools, data restrictions, human oversight of AI +5. **Incident reporting** — see something say something, blame-free culture, lost devices +6. **Governance and compliance** — policy structure, frameworks, risk, DR communication + +**Remember the basics:** + +- Use your CivicActions laptop with approved software +- Protect your identity with hardware MFA keys and strong passwords +- Handle data according to its classification level +- Never put sensitive data into AI tools +- Report anything suspicious — fast + +Questions? Reach out to **security@civicactions.com** or post in **Slack #general**. diff --git a/CP-02-cui-awareness-handling/README.md b/CP-02-cui-awareness-handling/README.md new file mode 100644 index 0000000..4f39e5b --- /dev/null +++ b/CP-02-cui-awareness-handling/README.md @@ -0,0 +1,220 @@ + + +# CUI Awareness & Handling + +Welcome to **CUI Awareness & Handling** — an additional training for CivicActions team members who work on federal contracts or projects that involve **Controlled Unclassified Information (CUI)**. + +This course builds on what you learned in *Security Awareness Essentials* (Training 1). It focuses specifically on the rules, boundaries, and markings that apply when you handle CUI. + +**Who takes this?** Staff assigned to federal contracts or projects involving CUI. + +**Prerequisite:** Training 1 — Security Awareness Essentials. + +**How long?** About 5-10 minutes. + +**When?** Before you're granted CUI access, then annually, and whenever there's a contract or policy change. + +**Compliance:** CMMC L2 (NIST 800-171), FAR 52.204-21. + +--- + +Let's get started! + +## Module A — What Is CUI and Why It Matters + +Before you can handle CUI properly, you need to understand what it is, who can access it, and why the rules exist. + +Here's a link to the full [**Controlled Unclassified Information (CUI) Policy**](https://civicactions.atlassian.net/wiki/spaces/MGPOL/pages/621641798/Controlled+Unclassified+Information+CUI+Policy) + +### CUI Defined + +**CUI** stands for **Controlled Unclassified Information**. It's government-created or government-owned information that requires safeguarding under federal regulation — specifically [**32 CFR Part 2002**](https://www.ecfr.gov/current/title-32/subtitle-B/chapter-XX/part-2002). + +CUI isn't classified (like "Secret" or "Top Secret"), but it's still sensitive. At CivicActions, examples of CUI include: + +- **Vulnerability scan results** from federal systems +- **Any document marked** "CUI" or "Controlled Unclassified Information" +- **Bids, proposals, and non-public contract data** -- also known as Federal Contract Informattion (FCI) + +> **Example:** Your team runs a vulnerability scan on a federal client's infrastructure and saves the results to a folder marked "CUI" within an access controlled Shared Drive. Those scan results are CUI — they reveal system weaknesses that could be exploited if leaked. They need to stay inside the CUI Security Boundary, not in a general project folder. + +> **Key point:** CUI has its own handling rules that go beyond CivicActions' standard "Confidential" classification. Even if you already know the data handling rules from the Security Essentials training, CUI adds an extra layer. + +> **Why it matters:** Failure to comply with these rules can affect CivicActions' contract eligibility. That means protecting CUI isn't just a best practice — it's a business requirement. + +### Module A Quiz + +A colleague who isn't assigned to your federal contract asks to see a CUI document for a blog post they're writing. What should you do? + +- [( )] Share it — they work at CivicActions, so they have access +- [( )] Share a redacted summary only +- [(X)] Decline — CUI access is limited to personnel with a legitimate business need on the specific contract +- [( )] Ask them to sign an NDA first +*** + +**Correct!** CUI access is governed by the need-to-know principle. Working at CivicActions doesn't automatically grant access to all CUI. The person must have a legitimate business need tied to the specific contract or project. Point them to their project lead if they believe they need access. + +*** + +## Module B — The CUI Security Boundary + +CUI can only live in specific, approved places. This module explains exactly where CUI is allowed — and where it absolutely is not. + +### Three Approved CUI Locations + +CUI may only be stored or processed in these three places: + +1. **Secured client network** — the client's own system, operating within their Authority to Operate (ATO) security boundary +2. **CivicActions Google Workspace** — specifically in **access-controlled Shared Drives** in folders that are explicitly marked **"CUI"** +3. **CivicActions managed workstations** — your CivicActions-issued laptop or an approved hardened BYOD device + +That's it. If a location isn't on this list, CUI doesn't belong there. + +> **Example:** Your team is working on a federal project. CUI goes in the project's dedicated CUI Shared Drive in Google Workspace — not in the team's general project folder, not in Confluence, and not in a Slack channel. If you need to collaborate on a CUI document, share it by individual @civicactions.com email within that Shared Drive. + +### Prohibited CUI Locations + +CUI must **never** be stored in: + +- **Personal cloud storage** (personal Google Drive, iCloud, Dropbox, OneDrive, etc.) +- **Unapproved SaaS platforms** (any tool not in the CUI Security Boundary) +- **Removable media** (USB drives, external hard drives) — unless you have explicit **CISO approval** +- **Personal email** +- **AI tools** — no CUI in ChatGPT, Gemini, Copilot, or any other AI platform +- **Slack** — do not share CUI data in any Slack channel or DM + +> **Remember:** Just because a tool is on the CivicActions Approved Software Catalog doesn't mean it's approved for CUI. The CUI Security Boundary is a much tighter set of locations. + +### Encryption Requirements + +CUI requires **FIPS 140–validated cryptography** for protection: + +- **In transit** — data must be encrypted when moving between systems (TLS, HTTPS, etc.) +- **At rest** — data must be encrypted where it's stored + +Before using any SaaS platform for CUI, verify that the provider's encryption meets the FIPS 140 standard. If you're not sure, ask IT. + +> **Example:** A teammate suggests storing CUI in a new cloud service that advertises "AES-256 encryption." That's not enough — for CUI, the encryption module itself must be FIPS 140-2 or 140-3 *validated*, which is a specific federal certification. The cloud provider also needs to meet FedRAMP Moderate compliance as well as be explicitly defined as within the CUI Security Boundary. Check with IT before putting CUI anywhere new. + +### Module B Quiz + +Where may CUI be stored? + +- [( )] Any CivicActions Google Drive folder +- [(X)] Only within the CUI Security Boundary: secured client network, access-controlled CivicActions Google Workspace Shared Drives marked "CUI", or managed CivicActions workstations +- [( )] Personal cloud storage with a strong password +- [( )] Any encrypted USB drive +*** + +**Right!** CUI has a strict Security Boundary. It can only live on the secured client network, in CivicActions Google Workspace Shared Drives that are explicitly marked "CUI" and access-controlled, or on CivicActions managed workstations. No personal cloud, no unapproved SaaS, no removable media without CISO approval, and no AI tools. + +*** + +## Module C — CUI Handling Rules + +Now that you know where CUI can live, here's how to handle it day to day. The rules are straightforward but strict. + +### No Unauthorized Transfer + +This is the most important rule: + +**Do not copy, print, download, or move CUI outside the Security Boundary.** + +That means: + +- Don't download CUI to a personal device +- Don't copy it to a general-purpose Shared Drive +- Don't print it unless you have a specific, approved reason — and if you do, shred it immediately after use +- Don't email it to a non-CUI-approved address + +If you need to move CUI for a legitimate reason, check with your project lead and IT first. + +> **Example:** You need to reference some vulnerability data from the CUI Shared Drive while writing a status report. Don't download the file to your desktop and paste snippets into a Google Doc in the general project folder. Instead, keep the CUI document in the CUI Shared Drive and reference it from there — or write the status report within the CUI boundary too. + +### Minimize Retention + +Don't hold onto CUI longer than you need it. + +- **Delete CUI copies** as soon as they're no longer needed for your current task +- Don't keep "just in case" copies +- The less CUI you retain, the smaller the risk if something goes wrong + +> **Example:** You downloaded a contractor bid document to review on your CivicActions laptop. Once you've finished your review and added your notes to the CUI Shared Drive, delete the local copy. Don't leave it sitting in your Downloads folder. + +### Project Closeout + +When a CUI project ends, there's a required cleanup process: + +1. Conduct a **CUI audit** as part of project closeout +2. Confirm that all CUI copies are either **returned to the client** or **securely destroyed** +3. Document the results + +This isn't optional — it's a project closeout requirement. + +### Incident Reporting for CUI + +If you suspect CUI has been **compromised, exposed, or mishandled**: + +- Report it as a **security incident immediately** +- Use the same channels: **Slack #general**, **DM an IT team member or your manager**, or email **security@civicactions.com** +- Don't try to "fix it" yourself first — speed is critical + +CUI incidents may trigger notification obligations to the government client, so the security team needs to know right away. + +> **Example:** You realize you accidentally shared a CUI Google Doc with someone outside the project by mistyping their email. Don't try to unshare it quietly and hope nobody notices — report it immediately to security@civicactions.com. The security team can assess the exposure, revoke access, and handle any required government notifications. + +### Module C Quiz + +A project involving CUI is ending. What must happen to CUI copies held by CivicActions? + +- [( )] Archive them indefinitely in case they're needed later +- [(X)] Include a CUI audit in project closeout — confirm all copies are returned to the client or destroyed +- [( )] Move them to a general-purpose Shared Drive +- [( )] Nothing — CUI protections expire when the contract ends +*** + +**Correct!** CUI protections don't expire when a contract ends. During project closeout, all CUI copies must be accounted for through a CUI audit and either returned to the client or securely destroyed. Archiving CUI "just in case" or moving it to a general-purpose drive would violate the Security Boundary rules. + +*** + +## Bonus Quiz + +You've completed all three modules — well done! Here's one final question on a key CUI concept. + +A teammate suggests pasting CUI data into an approved AI tool (like ChatGPT for Teams) to help draft a report. Is this allowed? + +- [( )] Yes — it's an approved tool, so all data types are permitted +- [( )] Yes — as long as you delete the chat afterwards +- [(X)] No — CUI must never be entered into any AI tool, even approved ones +- [( )] Yes — but only if the project lead approves +*** + +**Correct!** AI tools are explicitly listed as a **prohibited CUI location**, regardless of whether the tool is on the CivicActions Approved Software Catalog. The CUI Security Boundary is limited to the secured client network, CUI-marked Google Workspace Shared Drives, and managed workstations. No exceptions for AI tools. + +*** + +## Course Complete + +Congratulations — you've finished **CUI Awareness & Handling**! + +Here's what you covered: + +1. **What CUI is** — government-owned sensitive info regulated under 32 CFR 2002, with access limited by need-to-know +2. **The Security Boundary** — only three approved locations: client network, CUI-marked Shared Drives, managed workstations +3. **Handling rules** — no unauthorized transfer, minimize retention, CUI audit at project closeout, immediate incident reporting +4. **Document markings** — header ("CUI"), footer ("Sensitive in accordance with 32 CFR 2002"), and when markings are required + +**Remember the essentials:** + +- CUI can only live within the Security Boundary +- Never put CUI in personal storage, unapproved tools, or AI platforms +- Delete CUI copies when you no longer need them +- Mark documents properly when sharing outside the boundary +- Report any suspected CUI compromise immediately + +Questions? Reach out to **security@civicactions.com** or your project lead. diff --git a/CP-03-it-ops-change-config-patch/README.md b/CP-03-it-ops-change-config-patch/README.md new file mode 100644 index 0000000..c836ae3 --- /dev/null +++ b/CP-03-it-ops-change-config-patch/README.md @@ -0,0 +1,454 @@ + + +# IT Operations: Change, Configuration & Patch Management + +Welcome to **IT Operations: Change, Configuration & Patch Management** — the training for CivicActions IT staff, developers, and system/data owners. + +While all staff got a high-level awareness of these programs in Training 1, this course goes deeper. You're the people who actually *run* these programs, so you need to understand the details: configuration baselines, change classifications, patch timelines, privileged access rules, and disaster recovery operations. + +**Who takes this?** IT / Service Desk, Developers, System/Data Owners. + +**Prerequisite:** Training 1 — Security Awareness Essentials. + +**How long?** About 15–20 minutes. + +**When?** Within 30 days of onboarding, then annually, and whenever there's a major policy change. + +**Compliance:** CMMC L2 (CM, MA, SI controls), ISO 27001 A.8.9, A.8.32. + +--- + +Let's get started! + +## Module A — Configuration Management + +Configuration management is how we make sure our systems stay in a known, approved state. If someone changes something — intentionally or not — we need to know about it. + +Here's a link to the full [**Configuration Management Policy**](https://civicactions.atlassian.net/wiki/spaces/MGPOL/pages/767983618/Configuration+Management+Policy) + +### CI Scope + +CivicActions formally tracks five classes of **Configuration Items (CIs)**: + +1. **CIA "High" systems** — anything rated high for confidentiality, integrity, or availability +2. **Managed endpoints** — CivicActions laptops and other managed devices +3. **Cloud resources** — infrastructure we manage in cloud environments +4. **Production SaaS configurations** — settings for the SaaS tools we rely on +5. **Critical documentation** — policies, procedures, and architecture docs + +If it falls into one of these classes, it's under formal configuration control. + +> **Example:** Think about the Iru MDM profiles that enforce FileVault encryption and auto-lock on every CivicActions laptop. Those profiles are CIs under "Managed endpoints." And the Google Workspace SAML configuration that provides SSO across the company? That's a "Production SaaS configuration." Both are formally tracked. + +### CI Lifecycle + +Every CI follows three stages: + +1. **register** it when it enters service (add it to the CMDB with its baseline and owner), +2. **modify** it only through the change process (Standard, Normal, Significant, or Emergency — no cowboy changes), and +3. **retire** it when it's decommissioned (revoke access, archive the record, confirm no dependencies break). + +> If it's not tracked through all three stages, we can't prove we controlled it — and auditors will notice. + +### Configuration-as-Code + +At CivicActions, **Git is the authoritative baseline** for configurations: + +- Git history *is* the change history — every modification is tracked +- Jira and Confluence link to repos and pipelines for traceability +- If it's not in Git, it's not the official configuration + +### Baselines and Secure Defaults + +Every system starts from a **secure baseline**: + +- Apply **least functionality** — remove non-essential services and components +- Include **hardening settings**, identity/access parameters, and logging hooks +- Review baselines **at least annually** to make sure they're still appropriate + +> **Think of a baseline as the "factory settings" for security.** It's the known-good starting point that everything else builds from. + +> **Example:** A new CivicActions laptop starts from a Iru baseline — FileVault enabled, EDR installed, host firewall on, auto-lock at 15 minutes, and automated patching configured. That's the known-good state. If an engineer disables the firewall to troubleshoot a network issue and forgets to re-enable it, drift detection will catch it. + +### Drift Detection + +Sometimes systems drift away from their baseline — a setting gets changed, a package gets updated outside the process, etc. CivicActions uses **automated drift detection** to catch this: + +1. The system flags the deviation +2. A ticket is automatically created +3. The ticket must be **triaged within two business days** +4. Resolution: either **reconcile back to the baseline** or **raise a formal change request** to update the baseline + +Ignoring drift isn't an option. + +> **Example:** Iru detects that a developer's laptop no longer has the required EDR agent running. A Jira ticket is automatically created. The Service Desk triages it within two business days and finds the agent crashed after an OS update. They reinstall the agent, confirm compliance in Iru, and close the ticket — reconciled back to baseline. + +### Program Metrics, Evidence and Audit + +Configuration management produces records that auditors care about: + +- CI inventories +- Access approvals +- Baselines and their change histories +- Drift reports +- MDM (endpoint compliance) violations + +All of these are **Controlled Records** — keep them organized and up to date. + +### Module A Quiz + +Automated drift detection flags a configuration deviation on a production system. What is the required response? + +- [( )] Ignore it if the system is working +- [(X)] Triage within two business days — resolve by reconciling to baseline or raising a change request +- [( )] Immediately roll back all recent changes +- [( )] Wait for the annual baseline review +*** + +**Correct!** Drift must be triaged within two business days. The resolution is either to reconcile the system back to the approved baseline or to submit a formal change request to update the baseline. Ignoring drift or waiting for the annual review creates untracked risk. + +*** + +## Module B — Change Enablement + +Changes are inevitable — new features, security patches, configuration updates. Change enablement makes sure those changes happen safely, with the right reviews and approvals. + +Here's a link to the full [**Change Enablement Policy**](https://civicactions.atlassian.net/wiki/spaces/MGPOL/pages/768114689/Change+Enablement+Policy) + +### Change Classes + +CivicActions categorizes changes into four classes, each with different rules: + +| Class | What it is | Approval | +|-------|-----------|----------| +| **Standard** | Fully automated, pre-approved (e.g., routine patch waves) | No manual approval needed | +| **Normal** | Peer-reviewed PR/MR with delegated approval | Peer review + automated tests | +| **Significant** | Affects High Impact services | Formal Change Record + Change Authority approval + rollback plan | +| **Emergency** | During an active incident | Incident Commander authorized + post-incident review | + +> **Rule of thumb:** The bigger the blast radius, the more review it needs. + +> **Example:** Monthly OS patch waves pushed through Iru? That's a **Standard** change — automated, pre-approved, no manual sign-off needed. A developer opening a PR to update a service's Terraform config? **Normal** — peer review plus CI tests. Changing the Google Workspace password policy for all CivicActions users? **Significant** — you need a formal Change Record, Change Authority approval, and a rollback plan. Revoking a compromised API key during an active incident? **Emergency** — the Incident Commander authorizes it now, and the team does a full retrospective within 72 hours. + +### Change Record Content + +For Normal and Significant changes, the change record should include: + +- Description of the change +- Impacted services and CIs +- Impact and urgency assessment +- Risk assessment +- Test results +- Implementation plan +- **Backout plan** (how to undo it if something goes wrong) +- Maintenance window +- Evidence of completion + +### Approvals and Guardrails + +Each change class has specific guardrails: + +- **Normal:** Peer review + automated tests must pass +- **Significant:** Change Authority approval + documented rollback plan +- **Emergency:** Incident Commander authorizes in the moment; full review happens afterwards + +### Scheduling + +Changes don't happen whenever you feel like it: + +- Each service has a **weekly maintenance window** +- There's also a **monthly company calendar slot** for broader changes +- Changes outside these windows require **justification and additional approval** + +> **Example:** Each user-facing service — Google Workspace, Slack, Iru — has its own weekly maintenance window published on the company calendar. If you need to push a Significant change outside that window (say, a time-sensitive security configuration), you'll need to justify the timing and get additional approval. + +### Post-Implementation Review + +After a change goes live: + +1. **Verify** the change worked as expected +2. **Update configuration records** to reflect the new state +3. If something didn't go well, hold a **retrospective within 5 business days** +4. Capture **lessons learned** and feed them back into the process + +### Change Freezes + +Sometimes the organization needs stability more than new changes: + +- **Change freezes** are applied during critical delivery periods or when error budgets are exceeded +- During a freeze, only **stability-improving fixes** are permitted +- Everything else waits until the freeze is lifted + +### Module B Quiz + +You need to change a Google Workspace security setting that affects all CivicActions users. How should this change be classified? + +- [( )] Standard — it's just a settings toggle +- [(X)] Significant — it affects a company-wide service and requires a formal Change Record and Change Authority approval +- [( )] No classification needed for SaaS configuration changes +- [( )] Emergency — all company-wide changes are emergencies +*** + +**Correct!** A security setting change that affects every CivicActions user is a Significant change — it has a large blast radius. It requires a formal Change Record, Change Authority approval, and a rollback plan. Just because it's "one toggle" in a SaaS admin panel doesn't make it low-risk. + +*** + +## Module C — Vulnerability and Patch Management + +Finding and fixing vulnerabilities before attackers exploit them is one of the most impactful things we do. This module covers how CivicActions discovers, prioritizes, and remediates vulnerabilities. + +Here's a link to the full [**Vulnerability and Patch Management Policy**](https://civicactions.atlassian.net/wiki/spaces/MGPOL/pages/768344065/Vulnerability+and+Patch+Management+Policy) + +### Discovery Methods + +We find vulnerabilities through multiple channels: + +- **MDM/EDR** for endpoint vulnerabilities (OS, installed software) +- **SBOMs + SCA/SAST/DAST** for custom software (software bills of materials, static and dynamic analysis) +- **Vendor advisories** for SaaS platforms we use +- **Approved lists** for browser extensions, IDE plugins, and SaaS add-ons + +> **Example:** Iru continuously monitors laptops for missing OS patches and outdated software. Dependabot and Dependency-Track flag vulnerable libraries in your repos through pull requests. When a vendor like Atlassian publishes a security advisory for Confluence, the security team assesses it against our environment. These channels all feed into the same vulnerability management process. + +### Prioritization + +Not all vulnerabilities are equal. We prioritize based on: + +1. **Severity + exploitability** — how bad is it, and is it being exploited in the wild? +2. **Service criticality** — how important is the affected system? +3. **Data sensitivity** — what kind of data does the system handle? + +Before assigning remediation targets, confirm the vulnerability actually applies to your environment. + +### Remediation Timelines + +Once a vulnerability is confirmed and prioritized, here are the targets: + +| Severity | Remediation target | +|----------|-------------------| +| **Critical** | 15 days | +| **High** | 30 days | +| **Medium** | 60 days | +| **Low** | Best effort | + +> **Important:** These timelines **tighten during active exploitation**. If a Critical vulnerability is being actively exploited in the wild, 15 days may not be fast enough. Exceptions to timelines require **CISO approval**. + +### Staged Deployment + +Patches don't go straight to everyone at once: + +- **Endpoint patches:** MDM alpha group → beta group → company-wide rollout +- **SaaS config changes:** Validated in test/staging tenants first +- **Patch waves** are treated as **Standard changes** (pre-approved, automated) + +This staged approach catches problems before they affect the whole organization. + +> **Example:** A new macOS security update is released. Iru pushes it to the alpha group first — a small set of volunteer IT and engineering staff. They run it for a few days to catch compatibility issues. If nothing breaks, it goes to the beta group (a broader cross-section of teams). Only after beta validation does it roll out company-wide. If the alpha group hits a problem — say, the update breaks a VPN client — the rollout pauses before it affects anyone else. + +### Anti-Malware + +Malware protection is part of the vulnerability management program: + +- Maintain **current signatures** on all endpoints +- Run **periodic system scans** on a schedule +- Enable **real-time scans** for files downloaded from external sources + +### Verification + +Patching isn't done until it's verified: + +1. **Re-scan** the system or perform **functional validation** +2. **Attach evidence** to the remediation ticket +3. Reports and tickets are **Controlled Records** — retain them for audit + +### Module C Quiz + +A vulnerability scan identifies a Critical severity flaw in a production system. What is the remediation target? + +- [( )] Best effort during the next scheduled update +- [( )] 60 days +- [(X)] 15 days +- [( )] 30 days +*** + +**Right!** Critical vulnerabilities must be remediated within 15 days. And if the vulnerability is being actively exploited, the timeline may be even shorter. High is 30 days, Medium is 60 days, and Low is best effort. Any exceptions require CISO approval. + +*** + +## Module D — Endpoint Posture and Privileged Access + +Your endpoint is a high-value target for attackers. Privileged accounts are even more valuable. This module covers how to manage both responsibly. + +### Privileged Account Separation + +If you need admin-level access, you must use **separate accounts**: + +- **Standard account** for your daily work (email, Slack, docs) +- **Admin account** for elevated tasks (system administration, infrastructure changes) + +Before requesting elevated access, apply the **six-question privilege test** — basically, ask yourself: "Do I truly need this level of access, and is there a less-privileged way to accomplish the task?" + +> **Example:** You use your standard @civicactions.com account for Slack, email, and Google Docs all day. When you need to make changes in the Google Workspace Admin Console or push a Iru configuration profile, you switch to your separate admin account. If your everyday account gets phished, the attacker can read your email — but they can't touch admin settings. + +### NPI (Non-Person Identity) Management + +Service accounts and API keys are "non-person identities" (NPIs). They need care too: + +- Use **descriptive naming** so it's clear what the account does +- Every NPI must have a **linked human owner** +- Rotate credentials **quarterly** — or **immediately** if there's any sign of exposure + +> **Example:** Your team has a GitLab deploy token that CI/CD pipelines use to push container images. That token has a named human owner (the team's SRE lead), a descriptive name like `gitlab-deploy-projectx-prod`, and a quarterly rotation schedule in Jira. If the token appears in a log file by mistake, it gets rotated immediately — don't wait for the quarterly date. + +### Break-Glass Procedures + +Sometimes you need emergency access to a system when normal channels fail. That's what **break-glass procedures** are for: + +- Emergency credentials are **sealed** (not available for daily use) +- Access requires **dual control** (two people) +- After use: **mandatory audit** of what was done, followed by **credential rotation** + +Break-glass is for genuine emergencies — not for skipping the normal process. + +> **Example:** It's 2 AM and the Google Workspace admin account is locked out during an active incident. Two members of the SIRT use the sealed break-glass credentials together (dual control) to regain access. After the incident, they audit everything that was done with those credentials and rotate them immediately. The break-glass use is documented in the incident timeline. + +### MDM Posture Evidence + +CivicActions MDM generates records that prove device security: + +- **Remote wipe records** — evidence that lost/stolen devices were wiped +- **Compliance reports** — proof that devices meet minimum security standards +- **ITAD certificates** — documentation of proper device disposal +- **Cryptographic erasure** — FileVault/LUKS key destruction via MDM to securely sanitize devices + +These records are important for audits and for demonstrating that CivicActions takes endpoint security seriously. + +### Module D Quiz + +Why must admin accounts be separate from your daily-use account? + +- [( )] It's optional — a single account is fine if you use a strong password +- [( )] Admin accounts get more storage space +- [(X)] Separating accounts limits the damage if your daily-use account is compromised — an attacker wouldn't automatically get admin privileges +- [( )] CivicActions licenses require two accounts per person +*** + +**Correct!** Account separation is a core principle of least privilege. If your everyday account gets phished or otherwise compromised, the attacker only gets regular access — not admin control over critical systems. Keeping admin work on a separate account significantly limits the blast radius of an incident. + +*** + +## Module E — Disaster Recovery Operations + +When critical systems go down, we need a plan. This module covers how CivicActions classifies outages, recovers systems, and learns from incidents. + +Here's a link to the full [**Disaster Recovery Plan**](https://civicactions.atlassian.net/wiki/spaces/MGPOL/pages/915963911/Disaster+Recovery+Plan) + +### Incident Classification + +Outages are classified by severity so we know how urgently to respond: + +| Level | What it means | Example | +|-------|--------------|---------| +| **Low** | Minor issue, workaround available | A single SaaS feature is degraded but alternatives exist | +| **Medium** | Service unavailable, business impact | A key tool is down and work is disrupted | +| **High** | Multiple critical systems affected | Several production services are offline simultaneously | +| **Critical** | Prolonged outage, external impact | Extended downtime affecting clients or partner deliverables | + +### System-Specific Recovery + +CivicActions has documented recovery procedures for each critical system. You should know the **primary and fallback communication channels** and the **organizational actions** for the systems you manage, including: + +- Google Workspace, Slack, Zoom +- Iru (MDM) +- Atlassian (Jira/Confluence) +- Unanet, GitHub, GitLab +- Rippling, Culture Amp + +> **Google Workspace is the highest-priority recovery** because it's the SSO/identity provider. All other services depend on it for authentication. If Google is down, virtually everything else is affected. + +> **Example:** Slack goes down during a workday. The team shifts chat to Google Chat and video to Zoom — the documented fallback channels. If *Google Workspace* goes down, it's a different story: you can't authenticate to most other services. That's why Google is always recovered first. In that scenario, the primary communication fallback is Slack (chat) and Zoom (video), since they have independent authentication. + +### Backup Ownership + +For SaaS-based infrastructure: + +- **Primary backups are managed by the SaaS providers** — that's part of what we're paying for +- **Admin access** to backup and export features must be limited and documented +- Where available, use the platform's **export or backup features** for additional protection + +### Testing and Maintenance + +A disaster recovery plan that's never tested is just a wish: + +- The **DRP is reviewed annually** +- **Vendor DR assurances** are reviewed annually to confirm providers meet their commitments +- **Tabletop exercises** are conducted as appropriate — these are walk-throughs of "what if" scenarios + +> **Example:** During an annual tabletop exercise, the team walks through: "It's Monday morning and GitHub is completely down. What do you do?" Answer: developers use their local Git clones to keep working, the Service Desk monitors GitHub's status page, and if the outage extends, the team communicates workarounds via Slack. The exercise reveals that two teams forgot they had CI/CD pipelines dependent on GitHub Actions — that gets added to the recovery runbook. + +### Post-Incident Review + +After a major outage is resolved: + +1. Document the **timeline and impact** +2. Review the **effectiveness of the response** — what worked, what didn't +3. Track **improvement actions** and make sure they get done + +This feeds directly back into the DRP to make it better for next time. + +### Module E Quiz + +Google Workspace experiences a prolonged outage. Why is it classified as the highest-priority recovery? + +- [( )] It has the most storage +- [(X)] It is the SSO/identity provider — all other services depend on it for authentication +- [( )] Email is the most-used feature +- [( )] It's the cheapest to restore +*** + +**Correct!** Google Workspace is the identity backbone of CivicActions — it's the SSO provider. When Google is down, you can't authenticate to most other services either. That cascading effect is why it's always the top recovery priority. + +*** + +## Bonus Quiz + +You've completed all five modules — great work! Here's a final question covering a key concept from the course. + +During a change freeze, a developer wants to deploy a new feature that's been fully tested and reviewed. Should this be allowed? + +- [( )] Yes — it passed all tests, so it's safe to deploy +- [( )] Yes — but only if the developer's manager approves +- [(X)] No — during a change freeze, only stability-improving fixes are permitted; new features must wait +- [( )] Yes — change freezes only apply to infrastructure, not application code +*** + +**Correct!** Change freezes exist to protect stability during critical periods. Even fully tested new features must wait until the freeze is lifted. Only **stability-improving fixes** (like patches for active bugs or security vulnerabilities) are permitted during a freeze. This discipline prevents the "just one more thing" problem that can destabilize systems at the worst possible time. + +*** + +## Course Complete + +Congratulations — you've finished **IT Operations: Change, Configuration & Patch Management**! + +Here's what you covered: + +1. **Configuration management** — CI classes, Git as the authoritative baseline, secure defaults, drift detection, audit evidence +2. **Change enablement** — four change classes (Standard/Normal/Significant/Emergency), change records, scheduling, post-implementation review, change freezes +3. **Vulnerability and patch management** — discovery methods, prioritization, remediation timelines (Critical 15d / High 30d / Medium 60d), staged deployment, verification +4. **Endpoint posture and privileged access** — account separation, NPI management, break-glass procedures, MDM posture evidence +5. **Disaster recovery operations** — incident classification, system-specific recovery, backup ownership, testing, post-incident review + +**Remember the essentials:** + +- Git is the authoritative baseline — if it's not in Git, it's not official +- Classify changes properly — the bigger the blast radius, the more review required +- Patch Critical vulnerabilities within 15 days — faster if actively exploited +- Keep admin accounts separate from daily-use accounts +- Google Workspace is the #1 recovery priority because it's the identity provider + +Questions? Reach out to **security@civicactions.com** or your IT lead. diff --git a/CP-04-incident-response-responders/README.md b/CP-04-incident-response-responders/README.md new file mode 100644 index 0000000..4d88a67 --- /dev/null +++ b/CP-04-incident-response-responders/README.md @@ -0,0 +1,361 @@ + + +# Incident Response for Responders + +Welcome to **Incident Response for Responders** — the training for CivicActions team members who actively handle security incidents. + +Training 1 taught all staff to *report* incidents. This course teaches you how to *respond* to them: the IRP phases, evidence preservation, communications protocol, recovery objectives, and post-incident improvement. + +**Who takes this?** IT / Service Desk, SIRT (Security Incident Response Team) members, and Managers. + +**Prerequisite:** Training 1 — Security Awareness Essentials. + +**How long?** About 10–15 minutes. + +**When?** Within 30 days of onboarding, then annually, and after any significant incident (lessons learned). + +**Compliance:** CMMC L2 (IR.L2-3.6.1–3.6.3), ISO 27001 A.5.24–A.5.28. + +--- + +Let's get started! + +## Module A — IRP Structure and Phases + +Before you can respond to an incident effectively, you need to understand the plan that guides you. This module covers the document structure, the six response phases, and the principles that shape every decision. + +### Document Hierarchy + +CivicActions' incident response documentation has three layers: + +| Document | Purpose | +|----------|---------| +| [**Incident Response Policy**](https://civicactions.atlassian.net/wiki/spaces/MGPOL/pages/755367940/Incident+Response+Policy) | Defines principles, authority, and roles | +| [**Incident Response Plan (IRP)**](https://guidebook.civicactions.com/en/latest/common-practices-tools/security/incident-response-plan/) | The procedures followed when responding to security incidents | +| [**Incident Response Checklist**](https://guidebook.civicactions.com/en/latest/common-practices-tools/security/incident-response-checklist/) | A condensed IRP with step-by-step procedures for responders | +| [**Contingency Plan**](https://guidebook.civicactions.com/en/latest/common-practices-tools/security/contingency-plan/) | Recovery targets and integration with Disaster Recovery | + +During an active incident, the **Checklist** is your go-to reference. The IRP provides detailed procedures, and the Contingency Plan tells you how to prioritize recovery. + +> **Example:** A SIRT member gets pulled into an active phishing investigation. They don't need to re-read the full IRP — they open the Incident Response Checklist which walks them through each step: what to document, who to notify, how to contain. + +### Six Phases + +CivicActions follows six incident response phases: + +1. **Breathe** — Pause. Assess the situation calmly before acting. +2. **Document** — Start recording what you see, when you see it, and what you do. +3. **Initiate** — Activate the response: notify the right people, assemble the team. +4. **Assess** — Determine scope, severity, and impact. What systems are affected? What data is at risk? +5. **Remediate** — Contain the threat, eradicate it, and begin recovery. +6. **Conclude** — Close the incident, conduct the retrospective, and capture lessons learned. + +> **Safety and containment always come first.** Before you investigate, make sure the situation is contained. A fire investigator doesn't start looking for causes while the building is still burning. + +### Incident Declaration + +The **Incident Commander (IC)** is the person who: + +- **Declares** that an incident is happening +- **Assigns severity** based on impact and scope +- **Coordinates** the response team + +One important rule: if a security risk is discovered during an operational outage (like a routine system failure), it gets treated as a **security incident** — not just an ops issue. + +> **Example:** During a routine Jira outage investigation, the Service Desk notices that an admin account was used to export project data right before the outage. That's no longer just an ops issue — the IC declares a security incident, assigns a severity, and spins up the SIRT. The ops recovery continues in parallel, but the security investigation gets its own track. + +### Guiding Principles + +When making decisions during an incident, follow these principles: + +- **Reversible actions first** — prefer actions you can undo over ones you can't +- **Least privilege** — limit response access to what's needed +- **Limit the blast radius** — contain the problem to the smallest possible scope +- **Err on the side of containment** — when in doubt, contain first and investigate later + +> **Example:** You suspect a compromised service account is being used to access a Google Shared Drive. The reversible action is to disable the service account immediately — you can always re-enable it if it turns out to be legitimate. The *irreversible* action would be deleting the account or wiping the Drive. Contain first, investigate second. + +### Module A Quiz + +You notice unusual login attempts on a system you manage. What should you do first? + +- [( )] Investigate thoroughly and fix the issue yourself before telling anyone +- [(X)] Report the suspected incident immediately using IRP-designated channels +- [( )] Delete the suspicious logs to prevent further access +- [( )] Wait to see if it happens again before reporting +*** + +**Correct!** Speed matters in incident response. Report first, then help with the investigation. Trying to investigate alone wastes precious time, and deleting logs destroys the evidence the SIRT needs. The IRP is designed to coordinate the response across the team — so get the team involved immediately. + +*** + +## Module B — Evidence and Forensics + +Evidence is what turns "we think something happened" into "we know what happened." This module covers how to preserve it properly. + +### Preservation + +When an incident is in progress, evidence can disappear quickly. Here's how to protect it: + +- **Preserve logs, images, and artifacts** — don't modify, delete, or overwrite them +- Maintain **chain of custody** — document who had access to evidence, when, and what they did with it +- **Do not reimage, wipe, or disable logging** on affected systems without SIRT direction + +> **Example:** A developer notices that their CivicActions laptop is behaving strangely — unexpected network connections, high CPU usage. Their instinct is to wipe the machine and start fresh. But that would destroy the forensic evidence the SIRT needs. Instead, they report it to security@civicactions.com, keep the laptop powered on, and wait for SIRT guidance on next steps. + +> **Think of it like a crime scene.** You wouldn't clean up the evidence before investigators arrive. The same principle applies to digital incidents. + +### Coordination with SIRT + +Before you take action on evidence, coordinate: + +- Don't **acquire, copy, or analyze** data on your own without SIRT direction +- The SIRT may have specific procedures for how evidence should be collected +- Uncoordinated evidence collection can contaminate or destroy what the team needs + +If you find something relevant, **report it and wait for guidance** — unless immediate containment is needed to prevent further harm. + +### Controlled Records + +All incident records are [**Controlled Records**](https://civicactions.atlassian.net/wiki/spaces/MGPOL/pages/194019329/Document+and+Record+Control+Policy), which means they're subject to retention policy: + +- Incident logs and timelines +- Decision records (who decided what, and when) +- Artifacts (screenshots, log exports, configuration snapshots) +- Communication records + +Keep everything organized. Auditors and legal teams may need these records long after the incident is closed. + +> **Example:** During a phishing incident, the SIRT collects: the original phishing email (screenshot + headers), the Slack thread where it was first reported, the timeline of containment actions, the IC's severity assignment and decision log, and screenshots of the compromised account's recent activity. All of it goes into the incident's Jira ticket as attachments — organized and timestamped. Six months later, an auditor asks for the records. They're all in one place. + +### CUI During Response + +Incident urgency does not suspend CUI handling rules. Keep CUI on approved systems only — no Slack, personal email, or unauthorized tools. Apply CUI markings to incident records that reference it. The IC confirms which SIRT members are authorized to handle CUI for that engagement. + +### Module B Quiz + +During an incident investigation, you find a log file on an affected server that may contain key evidence. What should you do? + +- [( )] Copy it to your personal laptop for review +- [( )] Delete it so it doesn't fall into the wrong hands +- [(X)] Preserve it in place and coordinate with SIRT before acquiring, copying, or analyzing it +- [( )] Email it to the entire IT team for review +*** + +**Correct!** Evidence must be preserved with chain of custody intact. Don't copy it to personal devices, don't delete it, and don't distribute it broadly. Coordinate with SIRT — they'll tell you how to handle it properly. Uncoordinated actions can contaminate evidence or create legal complications. + +*** + +## Module C — Communications and Escalation + +During an incident, what you say — and who you say it to — matters enormously. This module covers the communications rules that keep everyone informed without making things worse. + +### Communications Officer + +All external and formal internal incident communications go through the **Communications Officer (CO)**: + +- The CO uses **approved channels and templates** +- No one else sends incident communications to clients, partners, media, or formal internal audiences +- If you're asked about the incident by someone outside the response team, direct them to the CO + +> **Example:** During an active incident involving a client project, a project manager from another team messages you on Slack: "Hey, I heard there's a security issue on Project X — is client data affected?" Even if you know the answer, the right response is: "The incident team is handling it — the Communications Officer will send an update when there's information to share." Need-to-know applies even inside CivicActions. + +### Update Standards + +When you do communicate about an incident (within the response team or as directed by the CO): + +- Keep updates **factual and time-stamped** +- Make them **audience-appropriate** — technical details for the response team, plain language for leadership +- **No speculation or attribution** in early updates — stick to what you know, not what you think + +> **Bad example:** "We think a hacker from Country X broke in through the VPN." +> +> **Good example:** "At 14:32 UTC, unusual login activity was detected on System X. Investigation is in progress." + +### Client and Third-Party Notifications + +Some incidents require notification to external parties: + +- **Vendor incidents** that may affect CivicActions or client data must be escalated +- Contracts — especially those involving **CUI or DoD data** — may require **time-bound external reporting** (typically 72 hours, some as short as 24 hours) +- The CO and IC determine when and how external notifications happen + +> **Example:** A SaaS vendor that CivicActions uses for a federal contract notifies you of a breach on their platform. The contract requires CivicActions to notify the government client within 72 hours. The IC and CO coordinate: the CO drafts the notification using the approved template, the IC reviews it for accuracy, and it goes out within the contractual window. For CUI-related contracts, that window could be as short as 24 hours. + +### Need-to-Know + +Incident details are shared on a **need-to-know basis**: + +- Don't discuss incident details outside designated channels (the incident Slack thread, SIRT meetings, etc.) +- No disclosure without **IC or CO approval** +- This protects the investigation and prevents misinformation + +### Module C Quiz + +During an active incident, a journalist contacts you asking for details. What do you do? + +- [( )] Provide basic facts to be transparent +- [(X)] Refer all media inquiries to the Communications Officer — do not disclose incident details without IC/CO approval +- [( )] Say "no comment" and hang up +- [( )] Direct them to the company website +*** + +**Correct!** All external communications during an incident go through the Communications Officer. Even well-meaning transparency can cause problems if the information is incomplete, inaccurate, or shared too early. The CO has the training and authority to handle media and external inquiries properly. + +*** + +## Module D — Recovery and Emergency Changes + +Once the threat is contained, the focus shifts to getting systems back to normal — safely. This module covers recovery priorities and the rules around emergency changes. + +### Recovery Targets + +Recovery is prioritized by **system criticality**, as defined in the Contingency Plan: + +- **Google Workspace** is always the highest priority — it's the identity provider, and many other services depend on it +- Other systems are prioritized based on their impact on business operations and client deliverables + +The Contingency Plan defines specific recovery time objectives for each critical system. Know the ones for the systems you manage. + +> **Example:** Google Workspace goes down on a Tuesday morning. Since it's the SSO provider, nobody can authenticate to Slack, Jira, or most other tools. The recovery priority is clear: Google first. The team shifts communication to Zoom (which has independent auth) and monitors the Google Workspace Status Dashboard. Once Google is restored, other services come back online as authentication resumes. + +### When IR Becomes Continuity + +The IC activates the Contingency Plan when a critical system won't recover within its recovery time objective, multiple systems are affected beyond normal IR scope, or recovery requires reconstitution from backups or failover. If recovery is clearly going to miss its recovery target, flag it to the IC immediately. + +### Emergency Changes + +During an incident, you may need to make changes fast — too fast for the normal change process. That's where **emergency changes** come in: + +1. The **Incident Commander authorizes** the change +2. **Document** what you're doing — during the incident if possible, immediately after if not +3. A **formal review** follows within **5 business days** + +Emergency authorization isn't a blank check. Document everything, and expect the review. + +> **Example:** During an active incident, the IC authorizes you to revoke all API tokens for a compromised GitLab service account. You make the change, note the time, the tokens revoked, and the IC's authorization in the incident Slack thread. Within five business days, the full change goes through a formal review — just like any other change, but after the fact. + +### Service Restoration + +Before you declare a system "back to normal": + +- **Verify system integrity** — make sure the system is clean and functioning correctly +- **Confirm containment** — verify that the threat is truly eliminated before restoring access +- Don't rush to reopen access if there's any doubt + +> **The worst thing you can do is restore access to a system that's still compromised.** Take the time to verify. + +> **Example:** After containing a compromised Google Workspace account, the temptation is to immediately re-enable it so the user can get back to work. But first: verify that the attacker's access is truly revoked, that all session tokens are invalidated, that the password and MFA method are reset, and that no malicious forwarding rules or OAuth grants remain. Only then do you restore access. + +### Module D Quiz + +During an incident, you need to make an emergency configuration change to contain a threat. What's the proper process? + +- [( )] Make the change and document it at the next scheduled team meeting +- [( )] Wait for Change Authority approval through the normal process +- [(X)] Get Incident Commander authorization, document the change during or immediately after, and complete a formal review within 5 business days +- [( )] Make the change without telling anyone to avoid slowing down the response +*** + +**Correct!** Emergency changes follow a streamlined but accountable process: IC authorization, real-time documentation (or as close to it as possible), and a formal review within 5 business days. Never skip documentation — it's critical for the post-incident review and for maintaining trust in the change process. + +*** + +## Module E — Post-Incident Learning + +The incident is over. Now comes one of the most valuable parts: learning from it. This module covers how CivicActions turns incidents into improvements. + +### Retrospective + +Within **5 business days** of closing an incident, the team conducts a **retrospective**: + +- The format is **blameless** — the goal is to understand *what happened*, not *who's at fault* +- Document the **timeline**, **impact**, and **response effectiveness** +- Identify what worked well and what needs improvement + +> **Blameless doesn't mean accountability-free.** It means we focus on systems, processes, and conditions rather than pointing fingers. People do their best with the information they have — so we fix the conditions that led to the problem. + +> **Example:** A retrospective reveals that a responder disabled a firewall rule during containment, which accidentally exposed another system for 20 minutes. The blameless discussion focuses on: "Why didn't the runbook mention this dependency? How can we add a pre-check step so future responders catch it?" That leads to an updated Incident Response Checklist — a process fix, not a blame assignment. + +### Risk Integration + +Lessons learned don't just sit in a document — they feed back into the organization: + +- Update the **Risk Register** with new risks identified during the incident +- Create **POA&Ms** (Plans of Action & Milestones) for trackable improvement items +- Route improvements through the **continual improvement process** + +> **Example:** After a phishing incident, the retrospective identifies that the team had no automated way to check if other users received the same phishing email. The improvement action becomes a POA&M ticket in the Jira Continual Improvement project: "Implement email header search capability for SIRT," with a milestone, an owner, and a due date. The Risk Register gets updated to reflect the gap until the capability is in place. + +### Personnel Matters + +If an incident involves personnel issues (policy violations, negligence, etc.): + +- Those matters are handled by **PeopleOps separately** +- Personnel actions are **not part of the IR process or retrospective** +- This separation protects the blameless culture of the retrospective while still allowing appropriate accountability + +### Compliance and Enforcement + +For serious or repeated violations: + +- Consequences may include **access revocation**, **disciplinary action**, or **contract remedies** +- These are determined outside the retrospective process +- The goal is always to improve — but willful or repeated violations have real consequences + +### Module E Quiz + +You receive a notification that a SaaS service used by CivicActions has experienced a data breach. What is the correct first step? + +- [( )] Immediately cancel the SaaS subscription +- [(X)] Report the vendor incident to security@civicactions.com so it can be escalated under the IR Policy +- [( )] Post about it in a public Slack channel so everyone is aware +- [( )] Wait for the vendor to contact CivicActions directly +*** + +**Correct!** Vendor incidents that may affect CivicActions or client data need to be escalated through the IR process. Report it to security@civicactions.com first. Don't cancel services unilaterally (that could disrupt operations), don't broadcast it publicly (need-to-know applies), and don't wait for the vendor to reach out — some contracts have tight notification deadlines. + +*** + +## Bonus Quiz + +You've completed all five modules — well done! Here's a final question on a key incident response concept. + +An incident retrospective reveals that a responder made a decision during the incident that, in hindsight, made things worse. How should this be handled? + +- [( )] Name the person publicly so everyone can learn from their mistake +- [( )] Skip it in the retrospective to avoid embarrassment +- [(X)] Discuss the decision in the blameless retrospective — focus on the conditions and information that led to it, and identify process improvements +- [( )] File a complaint with PeopleOps immediately +*** + +**Correct!** Blameless retrospectives focus on *conditions*, not individuals. The responder made the best decision they could with the information available at the time. The retrospective should explore *why* the decision seemed reasonable, *what information was missing*, and *how the process can be improved* so future responders have better tools and information. Personnel matters, if any, are handled separately by PeopleOps — never in the retrospective. + +*** + +## Course Complete + +Congratulations — you've finished **Incident Response for Responders**! + +Here's what you covered: + +1. **IRP structure and phases** — three-document hierarchy, six phases (Breath → Conclude), IC authority, guiding principles +2. **Evidence and forensics** — preserve with chain of custody, coordinate with SIRT, all records are Controlled Records +3. **Communications and escalation** — Communications Officer handles external comms, factual/time-stamped updates, need-to-know rules, time-bound client notifications +4. **Recovery and emergency changes** — IC-authorized emergency changes, document everything, verify integrity before restoring access +5. **Post-incident learning** — blameless retrospective within 5 days, lessons feed into Risk Register and POA&Ms, personnel matters handled separately + +**Remember the essentials:** + +- Report first, investigate as a team — don't go solo +- Preserve evidence — don't delete, reimage, or modify without SIRT direction +- All external communications go through the Communications Officer +- Verify system integrity before restoring access +- Retrospectives are blameless — focus on conditions, not individuals + +Questions? Reach out to **security@civicactions.com** or your SIRT lead. diff --git a/CP-05-secure-dev-supply-chain/README.md b/CP-05-secure-dev-supply-chain/README.md new file mode 100644 index 0000000..0e09e7f --- /dev/null +++ b/CP-05-secure-dev-supply-chain/README.md @@ -0,0 +1,312 @@ + + +# Secure Development & Supply Chain + +Welcome to **Secure Development & Supply Chain** — the security training built for CivicActions developers. + +You already know the security basics from Training 1, and your IT Ops colleagues covered the change/config/patch infrastructure in Training 3. This course focuses on what's specific to *your* work: writing secure code, using AI coding tools responsibly, managing open-source dependencies, and handling credentials properly. + +**Who takes this?** Developers — engineers, DevOps, and anyone writing or deploying code. + +**Prerequisite:** Training 1 — Security Awareness Essentials. + +**How long?** About 10–15 minutes. + +**When?** Within 30 days of onboarding, then annually, and whenever there's a toolchain or policy change. + +**Compliance:** CMMC L2 (SC, SI, SR controls), ISO 27001 A.8.25–A.8.28. + +--- + +Let's get started! + +## Module A — Secure Engineering Principles + +Security isn't something you bolt on at the end. It's something you build in from the start. This module covers the core principles that should guide every design decision and code change you make. + +### Shift-Left Security + +"Shift left" means moving security controls **earlier in the development process** — into your CI/CD pipeline, not just into a final review: + +- Use **pre-approved libraries** for authentication and cryptography (don't roll your own) +- Set up **automated baseline enforcement** in your pipelines — security checks run on every commit +- Catch problems in CI, not in production + +> **Example:** Your project uses a pre-approved authentication library that integrates with Google Workspace SAML. Your CI pipeline runs SAST and SCA checks on every pull request. A developer opens a PR that accidentally downgrades the library to a version with a known vulnerability — the pipeline catches it before the PR is even reviewed. That's shift-left in action. + +> **Think of it this way:** Fixing a security bug in a pull request costs minutes. Fixing one in production costs days — plus the incident response overhead. + +### Design Principles + +When designing systems, keep these principles in mind: + +- **Least privilege** — every component gets only the access it needs, nothing more +- **Zero trust** — don't assume any system or user is trusted by default, even inside the network +- **Rapid rollback** — design so you can undo changes quickly if something goes wrong +- **Defense in depth** — layer your security controls so that no single failure is catastrophic + +### DevSecOps Data Handling + +This one is simple but critical: + +- **Never use real PII, Confidential, or CUI data** in test or development environments +- **Do not export PII from SaaS platforms** for testing purposes +- **Use synthetic or masked datasets** instead — and submit masking scripts for review and approval before use +- **Store test data only in approved environments** — never on personal devices or unapproved platforms + +Production data in a test environment is a breach waiting to happen. Synthetic data gives you what you need without the risk. + +> **Example:** You're building a feature that displays user profiles. Instead of exporting real user data from Rippling or Google Workspace, you generate synthetic records with fake names, emails, and roles using an approved masking script. The script gets peer-reviewed to make sure it actually strips sensitive fields. The feature works the same way, but if the test environment gets compromised, no real PII is exposed. + +### Code Review Obligations + +Peer review isn't optional: + +- **All production code requires peer review** — no exceptions +- For **CIA "High" systems**, additional review rigor applies (more reviewers, more scrutiny) +- Code review is a security control, not just a quality check + +> **Example:** You're working on a CIA "High" system for a federal client. Your PR gets the usual peer review, but because of the system's classification, it also requires a second reviewer with security expertise. The extra rigor isn't bureaucracy — it's proportional to the risk. + +### Secure Defaults + +Ship your systems with security built in: + +- **Remove non-essential services and components** — if it's not needed, it shouldn't be there +- Start with **least-functionality baselines** — users and systems get the minimum by default +- Make the secure option the *easy* option + +### Module A Quiz + +You need test data that mirrors production for a new feature. What is the correct approach? + +- [( )] Copy production data into the test environment +- [( )] Export PII from the SaaS platform into a local database +- [(X)] Use synthetic or anonymized data — never use real PII or Confidential data in test/dev environments +- [( )] Ask a colleague to share their production access +*** + +**Correct!** Real PII or Confidential data must never be used in test or development environments. Use synthetic or anonymized data instead. Copying production data into test environments creates unnecessary risk — if the test environment is less secure (and it usually is), that data is now exposed. + +*** + +## Module B — AI-Assisted Development + +AI coding tools can make you faster, but they come with real responsibilities. This module covers the rules for using AI in your development workflow. + +Here's a link to the full [**AI Usage Policy**](https://civicactions.atlassian.net/wiki/spaces/MGPOL/pages/582418435/AI+Usage+Policy) + +### GitHub Copilot — The Only Approved Coding AI + +For **source code creation**, use only **GitHub Copilot** or a client-approved tool + +- Other approved AI tools (like ChatGPT for Teams or Gemini) can be used for **non-code technical queries** — architecture questions, documentation help, etc. +- Don't use non-approved AI tools for any development work + +> **Example:** You need help designing a database schema. GitHub Copilot is approved for writing the actual SQL or migration code. For a higher-level architecture question — "What's the best indexing strategy for this query pattern?" — you can use ChatGPT for Teams or Gemini. But a random AI tool you found online? Not approved, even if it looks helpful. + +### Review and Test Everything + +AI-generated code is **untrusted input** until you've verified it: + +- **Carefully review** all AI suggestions for correctness and security before committing + - **You are responsible** for the code you commit +- **Test** AI-generated code just like you'd test any code — unit tests, integration tests, security scans +- Never assume AI output is correct just because it looks reasonable + +> **AI tools are autocomplete on steroids — not a senior engineer.** They can produce code that compiles, passes basic tests, and still contains security vulnerabilities, logic errors, or license violations. + +> **Example:** Copilot suggests an authentication function that hard-codes a JWT secret as a string constant. It compiles and works in tests. But in a code review, you'd immediately flag it — secrets belong in an approved secret manager, not in source code. This is exactly the kind of thing AI tools get wrong. + +### Document AI Usage + +Transparency matters in code review: + +- **Describe AI assistance in your pull request description** so reviewers know which sections were AI-generated +- This lets reviewers apply **extra scrutiny** to those sections +- It's not about judgment — it's about making review more effective + +### No Sensitive Data in AI Tools + +This rule applies to all AI tools, including Copilot: + +- **Never use Confidential, Restricted, or CUI data** as prompts or context +- Don't paste production secrets, API keys, or customer data into any AI interface +- If you need to ask an AI tool about a pattern, use **generic or synthetic examples** + +> **Example:** You want to ask Copilot how to handle a specific API authentication flow for a federal client. Don't paste the real API endpoint, client credentials, or CUI data into the prompt. Instead, describe the pattern generically: "How do I implement OAuth2 client credentials flow with token rotation?" You get the same useful answer without exposing anything sensitive. + +### Module B Quiz + +You are using GitHub Copilot and it suggests a function that handles authentication. What should you do? + +- [( )] Accept it — Copilot is an approved tool +- [(X)] Review the suggestion carefully for correctness and security, test it, and note AI usage in your PR description +- [( )] Replace it with code from Stack Overflow +- [( )] Accept it but add a comment "AI generated" +*** + +**Correct!** Being an approved tool doesn't mean the output is automatically safe. Review AI-generated code carefully — especially security-sensitive functions like authentication. Test it thoroughly and document AI usage in your PR so reviewers know to give those sections extra attention. + +*** + +## Module C — Open-Source and Supply Chain + +Every open-source library you add to a project is a dependency — and a potential attack surface. This module covers how to treat third-party software with the care it deserves. + +Links to related [**Third‑Party Management Policy**](https://civicactions.atlassian.net/wiki/spaces/MGPOL/pages/745373710/Third+Party+Management+Policy) and [**Vulnerability and Patch Management Policy**](https://civicactions.atlassian.net/wiki/spaces/MGPOL/pages/768344065/Vulnerability+and+Patch+Management+Policy) + +### FOSS as Suppliers + +CivicActions treats open-source libraries and containers the same way we treat commercial vendors — as **suppliers** with risk scored on: + +- **Data touched** and required privileges +- **Security posture** (SBOM, disclosure policy, signed releases), and vendor trust/community health. +- **Assess maintainer health** — is the project actively maintained? How many contributors does it have? What is the update/patch velocity? +- **Triage known vulnerabilities** before adding a dependency +- **Verify license compliance** — some licenses have restrictions that may conflict with client contracts + +> **Example:** Before adding a new npm package to your project, you check: Does it have an SBOM? Are there any known CVEs? What's its license — is it compatible with the client's contract? When was the last commit? If the package has 1 contributor, no releases in 8 months, and 30 open security issues, that's a red flag — even if the API is exactly what you need. + +### SCA in CI/CD + +Your CI/CD pipeline should include automated security scanning: + +- **SCA** (Software Composition Analysis) checks third-party dependencies for known vulnerabilities + - CI/CD pipelines enforce **SBOM refresh** — the SBOM is updated on each release +- **SAST** (Static Application Security Testing) scans your code for common flaws +- **DAST** (Dynamic Application Security Testing) tests running applications +- Results feed into **Dependency-Track** for centralized visibility +- **Remediate Critical and High vulnerabilities before release** — these are blockers, not nice-to-haves + +> **Example:** Your CI pipeline runs Syft for dependency scanning and feeds results into Dependency-Track. On a Friday afternoon, a PR triggers a Critical vulnerability alert in a transitive dependency. It's tempting to merge and fix it Monday — but Critical and High findings are release blockers. You update the dependency, re-run the pipeline, and the alert clears before the PR is merged. + +### Unmaintained Components + +An open-source library that nobody is maintaining is a ticking time bomb: + +- Components with **no updates in over one year** must be assessed +- Options: **isolate** the component (limit its access and exposure), or **replace** it with an actively maintained alternative +- Don't wait for a vulnerability to be discovered — proactive assessment is required + +> **Example:** Your project uses a Node.js logging library that hasn't had a release in 14 months. No CVEs have been filed against it — yet. But per policy, it needs to be assessed. You check the repo: the sole maintainer hasn't responded to issues in months. The team decides to replace it with a well-maintained alternative rather than waiting for a vulnerability to surface. + +### Prohibited Technologies + +Before adding any new dependency or tool: + +- **Screen it against the [prohibited technology list](https://guidebook.civicactions.com/en/latest/company-policies/prohibited-hardware-and-software/)** +- Check for **DFARS restrictions** — some technologies are not permitted on DoD-related projects +- Do this at intake, not after you've already integrated it + +> **Example:** A developer on a DoD project wants to add a container image from a public registry. Before integrating it, they check: Is this image on the prohibited technology list? Are there DFARS restrictions that apply? Does the image come with an SBOM? These checks happen *before* writing the Dockerfile, not after the feature is built. + +### Module C Quiz + +An open-source library used in a project has not received any updates in over a year. What does the Third-Party Management Policy require? + +- [( )] Continue using it — open source is always safe +- [(X)] Treat it as unmaintained: assess maintainer health and isolate or replace the component +- [( )] Fork it and maintain it yourself without further review +- [( )] No action needed until a vulnerability is discovered +*** + +**Correct!** Open-source libraries without updates for over a year must be assessed. The options are to isolate the component (limit its access and blast radius) or replace it with an actively maintained alternative. Waiting for a vulnerability to appear is reactive — CivicActions requires proactive assessment. + +*** + +## Module D — Access and Identity for Developers + +Developers often have elevated access — to production systems, CI/CD pipelines, and infrastructure. This module covers how to manage that access responsibly. + +### SSH Keys and API Tokens + +Your SSH keys and API tokens are as sensitive as passwords: + +- Follow the **CivicActions naming conventions** so keys are identifiable +- Every key must be **linked to your individual identity** — no shared keys +- **Rotate** keys and tokens on schedule — **quarterly minimum** +- **Revoke immediately** on role change or departure + +> **A leaked API token is an open door.** Treat your keys with the same care as your password — and rotate them on schedule even if you don't think they've been exposed. + +> **Example:** Your SSH key for GitLab follows the naming convention `firstname.lastname-gitlab-projectx` so it's immediately identifiable. It's linked to your `firstname.lastname@civicactions.com` identity, and you have a quarterly Jira reminder to rotate it. When you move to a different project, you revoke the old key as part of the transition — don't leave stale keys lying around. + +### CI/CD Pipeline Credentials + +Pipelines need credentials too, and they have their own rules: + +- Use **separate service accounts per pipeline** — don't share service accounts across pipelines +- Apply **least privilege** — each pipeline gets only the access it needs +- **Never embed secrets in code or config files** — not in source code, not in environment files checked into Git +- Use **approved secret management tools** (like vault services) to manage pipeline secrets + +> **Example:** Your GitHub Actions workflow needs a deploy token for the production environment. Instead of putting it in a `.env` file committed to the repo, you store it in the repository's encrypted secrets (or an external vault). The pipeline pulls it at runtime, and it never appears in logs, code, or config files. If someone forks the repo, the secret doesn't come with it. + +### Risk Context + +Not all systems are equal, and you should know the difference: + +- Understand which systems are classified as **CIA "High"** — these require extra controls +- Apply **proportional controls**: more peer review, formal change records, stronger encryption +- Know how to check the **Risk Register** for system classifications + +If you're unsure whether a system requires elevated controls, check the Risk Register or ask your project lead. + +> **Example:** You're assigned to a new project and aren't sure about its CIA classification. You check the Jira Continual Improvement project where the Risk Register lives and see the system is rated CIA "High" for confidentiality. That means: additional code review rigor, formal change records for significant changes, FIPS-validated encryption for data at rest and in transit, and quarterly access reviews. Knowing this upfront shapes how you work from day one. + +### Module D Quiz + +Where should CI/CD pipeline secrets (like API keys and service account credentials) be stored? + +- [( )] In environment variables within the Git repository +- [( )] In a shared document accessible to the dev team +- [(X)] In approved secret management tools — never embedded in code or config files +- [( )] In comments within the pipeline configuration file +*** + +**Correct!** Secrets must never be stored in code, config files, or Git repositories — even in environment variable files that are committed. Use approved secret management tools (vault services) that provide encryption, access control, and audit logging. Shared documents are also not acceptable — they lack the security controls that proper secret management provides. + +*** + +## Bonus Quiz + +You've completed all four modules — excellent work! Here's a final question on a key development security concept. + +You're starting a new project and need to implement user authentication. What's the best approach? + +- [( )] Write a custom authentication library from scratch to meet the project's exact needs +- [( )] Copy authentication code from a previous project without reviewing it +- [(X)] Use a pre-approved authentication library and integrate it with automated security checks in the CI/CD pipeline +- [( )] Let the AI coding tool generate the entire authentication system and deploy it directly +*** + +**Correct!** "Shift-left" means using **pre-approved libraries** for security-critical functions like authentication — not building from scratch. Custom authentication code is one of the most common sources of security vulnerabilities. Pre-approved libraries have been vetted, and integrating them with automated CI/CD security checks means problems are caught early, not in production. + +*** + +## Course Complete + +Congratulations — you've finished **Secure Development & Supply Chain**! + +Here's what you covered: + +1. **Secure engineering principles** — shift-left security, design principles (least privilege, zero trust, defense in depth), no real data in test environments, mandatory code review +2. **AI-assisted development** — Copilot only for code, review and test all AI output, document AI usage in PRs, no sensitive data in prompts +3. **Open-source and supply chain** — treat FOSS as suppliers, SCA/SAST/DAST in CI/CD, assess unmaintained components, SBOM at intake, screen against prohibited tech lists +4. **Access and identity** — rotate SSH keys and tokens quarterly, separate pipeline service accounts, use secret management tools, know your CIA "High" systems + +**Remember the essentials:** + +- Use pre-approved libraries for security-critical functions — don't roll your own +- Treat AI-generated code as untrusted input — review, test, and document it +- Every open-source dependency is a supply chain link — assess it before you add it +- Never put secrets in code or config files — use proper secret management +- Know which systems are CIA "High" and apply proportional controls + +Questions? Reach out to **security@civicactions.com** or your engineering lead. diff --git a/CP-06-access-governance-risk-supplier/README.md b/CP-06-access-governance-risk-supplier/README.md new file mode 100644 index 0000000..1dabf8d --- /dev/null +++ b/CP-06-access-governance-risk-supplier/README.md @@ -0,0 +1,486 @@ + + +# Access Governance, Risk & Supplier Oversight + +Welcome to **Access Governance, Risk & Supplier Oversight** — the training for CivicActions managers, system/data owners, and document controllers. + +While Training 3 covers the technical operations, this course covers the **governance decisions** you make: approving and reviewing access, managing risk, overseeing supplier relationships, and controlling documents. These are the "approve, review, decide" responsibilities that keep the organization running securely. + +**Who takes this?** Managers, System/Data Owners, Document Controllers. + +**Prerequisite:** Training 1 — Security Awareness Essentials. + +**How long?** About 15–20 minutes. + +**When?** Within 30 days of onboarding, then annually, and whenever there's a major policy change. + +**Compliance:** CMMC L2 (AC, RA, SR controls), ISO 27001 A.5.1–A.5.23. + +--- + +Let's get started! + +## Module A — Access Governance + +As a manager or system owner, you're the gatekeeper for who gets access to what. This module covers your approval responsibilities, the access lifecycle, and the reviews that keep permissions current. + +See also: [**Access Control Policy**](https://civicactions.atlassian.net/wiki/spaces/MGPOL/pages/744947714/Access+Control+Policy) + +### Common Access Governance Themes + +- **Default-Deny / Zero Trust:** No access until there's a justified reason. Every request is untrusted until proven otherwise — being on the network doesn't count. +- **SSO-First:** Google Workspace is the front door. If a tool supports SSO, native passwords get disabled. No shadow accounts, no shared logins. +- **Separation of Duties:** Requester, approver, and implementer must be three different people. You cannot approve your own access. +- **Privileged Access:** If an account can change permissions, bypass controls, access all data, alter configs, touch audit logs, or do something irreversible — it's privileged. Separate admin accounts, just-in-time elevation, two-person authorization for destructive actions. +- **Non-Person Identities:** Service accounts, bots, API keys, and tokens follow the same lifecycle as human accounts - registered, scoped, reviewed quarterly, revoked when done. Every one has a human owner on record. +- **The 24-Hour Rule:** Access is disabled the day someone separates. Full removal — accounts, tokens, group memberships - within 24 hours, no exceptions. + +### The Approval Role + +When someone requests access to a system or project, you're the one who decides whether to approve it. Here's what guides that decision: + +- Apply the **principle of least privilege** — grant only the minimum access needed +- Apply **need-to-know** — does this person actually need this access for their current work? +- Scope access to the specific **project, role, or task** — not broad access "just in case" + +> **If you're unsure, start with less access.** It's always easier to grant more later than to clean up over-provisioned access after a problem. + +> **Example:** A new team member submits a Jira ticket requesting access to the production Google Cloud environment. The ticket includes their name, the specific project, their justification, and the role they need. As the System Owner, you check: does their current assignment actually require production access, or would staging be sufficient? You approve staging access and note that production can be added later if the project scope expands. + +### Access Lifecycle + +Access follows a predictable lifecycle — and you have a role at every stage: + +1. **Approve** — review and approve (or deny) the request +2. **Grant** — IT provisions the access +3. **Review** — periodically verify the access is still needed +4. **Revoke** — remove access when it's no longer needed + +Three events should trigger an **immediate rights review**: + +- **Role changes** — someone moves to a different team or function +- **Project transitions** — someone finishes one project and starts another +- **Departures** — someone leaves the organization + +Don't wait for the quarterly review when someone's situation changes. + +> **Example:** One of your developers finishes a federal contract and moves to an internal project. You don't wait until the next quarterly review — you trigger an immediate rights review. IT removes their access to the CUI Shared Drive, the client's cloud environment, and the project-specific GitLab group. Then you submit a new request for the access they need on their new project. Rippling's offboarding workflow handles some of this automatically, but system-specific access like Shared Drives and GitLab groups needs your attention. + +### Periodic Access Reviews + +Even without role changes, access should be reviewed regularly: + +- Conduct **quarterly reviews** of access rights for your team +- **Verify continued need** for each permission +- **Revoke orphaned or excessive permissions** — these are permissions nobody needs anymore + +Stale access is a common audit finding and a real security risk. + +> **Example:** During your quarterly access review of high-criticality systems — the IdP, production cloud, CI/CD, and CUI boundary — you discover that two people who rotated off a project three months ago still have access to that project's GitLab group and Google Shared Drive. You revoke both immediately and file Jira tickets documenting the cleanup. This is exactly the kind of finding auditors look for. + +### Third-Party and Contractor Access + +External people — contractors, consultants, partners — need the same controls as employees. In some ways, they need more: + +- Apply the **same least-privilege and need-to-know principles** +- Make access **time-bound** — set an expiration date, don't leave it open-ended +- Ensure **contractual security obligations** are in place before granting any access + +> **Example:** A subcontractor needs Jira and Confluence access for a six-month engagement. You approve time-bound access that expires at the contract end date, require that their device meets CivicActions endpoint standards (or they use a managed device), and confirm that the subcontract includes the required security clauses — confidentiality, least-privilege, and incident reporting within 24 hours. + +### CUI Access Decisions + +Access to Controlled Unclassified Information (CUI) has extra requirements: + +- CUI access requires **explicit justification** — not a blanket grant +- Access is limited to the **CUI Security Boundary** (covered in Training 2) +- As a manager, you must **verify need-to-know** for each team member before approving CUI access + +> **Example:** A team member asks for access to the CUI Shared Drive for a federal project. Before approving, you verify: Are they assigned to this contract? Does their role require CUI access? You approve with an explicit justification in the ticket — "Developer assigned to Project X, needs vulnerability scan data for remediation work" — rather than a blanket "they're on the team." + +### Module A Quiz + +A team member is transferring from Project A to Project B. As their manager, what must you do regarding their access? + +- [( )] Nothing — their access will sort itself out +- [( )] Wait for the quarterly access review to clean up permissions +- [(X)] Trigger an immediate rights review to remove Project A access and request Project B access +- [( )] Ask the team member to manage their own access changes +*** + +**Correct!** Project transitions are one of the three events that require an immediate rights review. Don't wait for the quarterly cycle — remove Project A access right away and request only the access needed for Project B. Leaving old access in place creates unnecessary risk and violates the principle of least privilege. + +*** + +## Module B — Risk Management Responsibilities + +Risk management can sound complicated, but at its core it's about answering three questions: *What could go wrong? How bad would it be? What are we doing about it?* This module covers your role in that process. + +See also: [**Risk and Security Assessment Policy**](https://civicactions.atlassian.net/wiki/spaces/MGPOL/pages/710213648/Risk+and+Security+Assessment+Policy) + +### Risk Assessment Participation + +As a system or data owner, you contribute to risk assessments for the systems you manage: + +- Understand the **CIA matrix**: Confidentiality, Integrity, and Availability — each system is rated for all three +- Understand the **3×3 risk scale**: Likelihood (Low/Medium/High) × Impact (Low/Medium/High) +- Your input matters — you know your systems better than anyone + +> **Example:** During a risk assessment for a project management tool, you rate it: Confidentiality = Medium (it holds project plans and timelines, but no CUI), Integrity = Medium (corrupted data would disrupt work but is recoverable from backups), Availability = High (the team can't function without it). Those CIA ratings go into Jira assets and drive the controls that apply to the system. + +### Risk Treatment Options + +When a risk is identified, there are four ways to handle it: + +| Option | What it means | +|--------|--------------| +| **Mitigate** | Reduce the risk by adding controls | +| **Transfer** | Shift the risk to someone else (e.g., insurance, a vendor SLA) | +| **Accept** | Acknowledge the risk and decide to live with it | +| **Avoid** | Eliminate the risk by stopping the activity | + +> **Key point:** Risk acceptance must be **explicit and recorded**. You can't just ignore a risk and call it "accepted." + +> **Example:** Your team identifies a risk: a SaaS tool you depend on doesn't support hardware-key MFA — only TOTP. The impact is Medium (credential theft is harder to prevent) and the likelihood is Low (the tool is internal-only). That's a Low residual risk. You accept it as the System Owner with CISO concurrence and document the rationale in a Risk Mitigation ticket in the Jira Continual Improvement project. "Ignore" is never an option — even Low risks get documented. + +### Risk Acceptance Authority + +Not everyone can accept every level of risk. The authority depends on severity: + +| Residual risk level | Who can accept it | +|--------------------|-------------------| +| **Medium** | System Owner | +| **High** | CISO | +| **Above High** | CEO (or CTO as backup) | + +If a risk is too high for your authority level, escalate it. + +### Risk Register and POA&Ms + +The Risk Register is the central record of all identified risks: + +- Maintain awareness of **your systems' entries** in the register +- Make sure **POA&M items** (Plans of Action & Milestones) have assigned owners, realistic timelines, and tracked progress +- POA&Ms aren't just paperwork — they're commitments to fix things + +> **Example:** A risk assessment finds that one of your systems doesn't have automated drift detection yet. The CISO creates a POA&M ticket in the Jira Continual Improvement board: "Implement automated configuration drift detection for System Y." It has your name as the owner, a due date in 90 days, and milestones for tool selection, testing, and deployment. The ELT sees its status in the quarterly risk report. + +### Annual Risk Review + +Risk isn't static — it changes as systems, threats, and business conditions evolve: + +- Participate in the **annual reassessment** of risks for your systems +- **Update entries** when systems change, new threats emerge, or the business context shifts +- Don't wait for the annual cycle if something significant changes — update the register immediately + +### Module B Quiz + +A risk assessment identifies a High residual risk for a system you own. Who must approve acceptance of this risk? + +- [( )] You (the System Owner) +- [(X)] The CISO +- [( )] Any manager on the team +- [( )] The risk is automatically accepted if documented +*** + +**Correct!** System Owners can accept Medium residual risk, but High residual risk requires CISO approval. Risks above High require CEO (or CTO as backup) approval. Simply documenting a risk doesn't mean it's accepted — explicit approval from the right authority level is required. + +*** + +## Module C — Supplier and Third-Party Oversight + +CivicActions relies on vendors and partners for many critical services. This module covers how to evaluate, onboard, and monitor those relationships securely. + +See also: [**Third‑Party Management Policy**](https://civicactions.atlassian.net/wiki/spaces/MGPOL/pages/745373710/Third+Party+Management+Policy) + +### Three SCRM Tracks + +CivicActions uses three Supply Chain Risk Management tracks, depending on the type of supplier: + +| Track | Supplier type | Examples | +|-------|--------------|---------| +| **SCRM-DS** | Digital services / SaaS | Google Workspace, Slack, cloud platforms | +| **SCRM-S** | Software | Open-source libraries, commercial software, containers | +| **SCRM-PS** | Professional services | Consultants, subcontractors, staffing agencies | + +Know which track applies to the suppliers you manage. + +> Each track has different intake requirements, evidence expectations, and monitoring cadences. + +### Risk Tiering + +Each supplier is categorized as **Low**, **Medium**, or **High** based on different factors: + +- **SaaS (SCRM-DS):** CIAX scoring — how much confidential, integrity-critical, or availability-critical data do they handle? +- **Software (SCRM-S):** Security posture and SBOM (Software Bill of Materials) analysis +- **Professional services (SCRM-PS):** Level of access, criticality to operations, and regulatory scope + +Higher-tier suppliers get more scrutiny. + +> **Example:** You're evaluating a new SaaS tool for project analytics. You run the CIAX scoring: it handles Internal data (moderate C), has no integrity-critical role (low I), the team could work without it for a week (low A), and the annual cost is modest (low X). That scores as Low tier — fast-path intake with an annual review. If the same tool handled CUI or was critical to client deliverables, it would score High and require a full review with third-party evidence. + +### Mandatory Due Diligence + +This is a firm rule: + +**No supplier may be procured, deployed, or granted access until tier-appropriate due diligence is complete.** + +Due diligence includes: + +- **Intake form** capturing the supplier's purpose and data handling +- **Evidence review** of security certifications, audit reports, etc. +- **Security questionnaire** for Medium and High-tier suppliers + +Don't skip this because of time pressure. A vendor without due diligence is an unknown risk. + +> **Example:** A project lead wants to start using a new SaaS collaboration tool next week. You walk them through the process: submit the intake form (business owner, data classification, intended use), then evidence review (does the vendor have SOC 2 or ISO 27001 certification?). For a Medium-tier tool, a SIG Lite questionnaire is also required. The tool doesn't get deployed until this is done — no exceptions, even with a deadline. + +### Protecting Commercial Data in Supplier Relationships + +Before granting any supplier or partner access to project data, treat the data correctly: + +- **Proposals, RFPs, and technical diagrams** are **Confidential by default** — store them only in designated Shared Drives or authorized CUI enclaves, never on personal devices or unapproved platforms +- **Brief subcontractors and partners on data handling requirements before granting access** — don't rely on contract clauses alone; walk them through what's expected +- **Confirm understanding** — get written acknowledgment that the partner knows the rules before they touch project data + +> **Example:** A subcontractor is joining your federal project next week. Before you approve their access to the project Shared Drive, schedule a 15-minute briefing: where CUI lives, what can and can't be shared externally, and how to report a mistake. Have them confirm they understand. Skipping this step is one of the most common ways sensitive data ends up in the wrong place. + +### Data Minimization as a Management Responsibility + +As a manager, you set the standard for how much data your team collects and retains: + +- **Collect only what's necessary** — if your team doesn't need a data element to do the work, don't collect it +- **Grant access strictly on a need-to-know basis** — even within your own team, not everyone needs everything +- **Verify that project data stays in approved locations** — spot-check that team members aren't storing files locally or in personal cloud accounts + +> **Example:** Your team is starting a new engagement and setting up a project Shared Drive. Before populating it, think about what's actually needed — don't copy over an entire folder of data from a previous project "just in case." Share only the documents required for the current scope, and limit access to the team members who need them. + +### Required Contract Clauses + +Every supplier contract must include specific security clauses: + +- **Confidentiality** obligations +- **Least-privilege** access requirements +- **Encryption** and **MFA** requirements +- **Incident reporting** within **24 hours** +- **Right to audit** +- **Federal flow-down** clauses (FAR/DFARS) for suppliers handling FCI or CUI +- **Change notification** — the vendor must tell us before making significant changes +- **Exit and data destruction** — what happens when the contract ends + +> **Example:** When negotiating a contract with a cloud storage vendor, you ensure it includes: incident reporting within 24 hours, encryption in transit and at rest, MFA for admin access, and right to audit. The vendor will also handle CUI for a federal project, so the contract adds FAR 52.204-21 flow-down, DFARS 252.204-7012, and a requirement for FedRAMP Moderate equivalence. Exit terms specify that all CivicActions data is returned or destroyed, with sanitization artifacts provided. + +### Monitoring Cadence + +Due diligence isn't a one-time event: + +| Supplier tier | Review frequency | +|--------------|-----------------| +| **Low / Medium** | Annually | +| **High** | Semi-annually | + +Additionally, trigger an **ad-hoc review** for: + +- Security incidents involving the supplier +- Scope changes (the supplier starts handling more sensitive data) +- Introduction of new data classes +- Annual PM-led reviews for professional services + +### Prohibited Technologies + +Before onboarding any supplier or technology: + +- **Screen against the prohibited technology list** +- Check for **DFARS restrictions** — some technologies cannot be used on federal projects +- Do this at intake *and* during periodic reviews — prohibitions can change + +### Module C Quiz + +A new SaaS vendor is proposed that will process CivicActions data. What must happen before procurement? + +- [( )] Nothing — just sign up and start using it +- [(X)] Tier-appropriate due diligence must be completed, including intake form and evidence review, before the vendor is procured, deployed, or granted access +- [( )] Only a cost comparison is required +- [( )] The vendor just needs to sign an NDA +*** + +**Correct!** No supplier gets procured, deployed, or granted access until proper due diligence is complete. That includes an intake form, evidence review, and (for Medium/High-tier suppliers) a security questionnaire. An NDA alone doesn't address technical security requirements, and cost is not a substitute for security evaluation. + +*** + +## Module D — Document and Record Control + +Controlled Documents are the policies, procedures, and records that define how CivicActions operates. This module covers how they're managed. + +See also: [**Document and Record Control Policy**](https://civicactions.atlassian.net/wiki/spaces/MGPOL/pages/194019329/Document+and+Record+Control+Policy) + +### Document Identification + +Controlled Documents are tracked in the **Controlled Document Jira board**. Each document gets a unique ID: + +**Format:** Two-character department prefix + document type digit + three-digit unique number + +For example: `IT-1-001` might be an IT policy document. + +> **Example:** The IT department (prefix "IT") publishes a new policy (type digit "1"), and it's the third document in the series (serial "003"). Its ID is `IT-1-003`. A security team checklist would be something like `SC-4-012` — Security (SC), checklist (4), twelfth document. These IDs live on the Controlled Document Jira board and never get reused, even if a document is retired. + +### Classification + +Every Controlled Document gets a data classification: + +- Apply the **four-level classification** (Public, Internal, Confidential, Restricted) using the Data Classification SOP +- Record the classification in the **Document Control Change Log** +- Classification determines who can access the document and how it must be handled + +### Version Control + +CivicActions uses a clear versioning system: + +| Version type | When to use it | Examples | +|-------------|---------------|---------| +| **Major** | Significant content or scope changes | New section added, policy requirement changed | +| **Minor** | Small corrections | Typos fixed, broken links updated, formatting improved | + +One critical rule: **effective Controlled Documents are immutable**. You don't edit a live document — you create a new draft, get it approved, and publish a new version. + +> **Example:** The Access Control Policy is currently at version 2.0. Someone notices that a referenced Confluence link is broken and a section heading has a typo. They don't edit version 2.0 directly — they submit a Document Change Request through the Compliance Jira board. The Document Controller creates a draft (version 2.1), the Responsible Person reviews it, and once approved, 2.1 becomes the new controlled copy. Version 2.0 is archived, not modified. + +### Change Request Process + +To change a Controlled Document: + +1. **Submit** a request through the **Compliance Jira board** +2. The document goes through the workflow: **Draft → Feedback → Approval → Distribution** +3. The approved version becomes the new **controlled copy** + +### Training Coordination + +When a Controlled Document changes, people may need training on the update: + +- **Management and the Responsible Person** determine training requirements for each document +- The **Document Controller** coordinates training planning +- Not every change requires training — but significant ones do + +### Annual Review + +All Controlled Documents are reviewed annually by default: + +- The review confirms the document is still accurate and relevant +- Documents with **different review schedules** note this in their Review section +- Don't skip the annual review — even if nothing seems to have changed, the review itself is a compliance requirement + +### Module D Quiz + +A colleague submits a change to a Controlled Document that corrects a typo and updates a broken link. How is this version classified? + +- [( )] Major version — all changes are major +- [(X)] Minor version — typos, link updates, and formatting are minor changes +- [( )] No version change needed for typos +- [( )] Emergency version — broken links need immediate fixes +*** + +**Correct!** Typos, broken links, and formatting corrections are minor version changes. Major versions are reserved for significant content or scope changes. And no, you can't skip versioning entirely — even small corrections create a new version because effective Controlled Documents are immutable. + +*** + +## Module E — AI Governance for Managers + +AI tools are becoming part of how work gets done. As a manager, you have specific governance responsibilities around their use. + +See also: [**AI Usage Policy**](https://civicactions.atlassian.net/wiki/spaces/MGPOL/pages/582418435/AI+Usage+Policy) + +### Condensed AI Usage Policy + +- **No Sensitive Data in AI Tools:** Never input confidential, proprietary, or CUI data into any AI tool — external or internal. If you wouldn't paste it into a public chat, don't paste it into a prompt. +- **IT-Managed Accounts Only:** Use CivicActions-approved AI tools through IT-managed accounts. No personal accounts, no free-tier signups, no "I just wanted to try it." +- **Label and Review:** AI-generated content must be clearly labeled as AI-assisted and peer-reviewed by a human before any business use. AI drafts it, a person owns it. +- **GitHub Copilot for Code:** Copilot is the approved tool for AI-assisted code generation. Other code-generation tools require CTO approval before use. + +### AI Approval Authority + +New AI tools (or significant new uses of existing tools) require approval: + +- **CTO approval** is required for any new AI tool or significant new application +- On **client projects**, you also need **client approval** +- This isn't just bureaucracy — it ensures every AI tool gets a proper security and risk review + +> **Example:** A manager wants to pilot a new AI-powered code review tool for their team. Even though the team already uses GitHub Copilot (approved for code), a new tool requires CTO approval. The manager submits the request, which triggers a risk assessment guided by the NIST AI Risk Management Framework: What data does the tool access? What happens if its suggestions are wrong? Does it meet CivicActions' security standards? On a client project, the client's approval is also needed before the tool touches any project code. + +### Sales Restrictions + +AI has specific limits when it comes to sales activities: + +- **No AI tools for pricing** — pricing decisions must be human-made +- **No AI for original RFP content generation** — AI cannot write proposal content from scratch +- **AI may assist** with analysis, review, and rewriting — but a human must create the original content + +> **Why?** Pricing and proposals are high-stakes, client-facing outputs. AI-generated content in these areas creates accuracy risks, contractual risks, and trust risks. + +> **Example:** Your team is responding to a federal RFP. AI tools like ChatGPT for Teams can help you review and rewrite sections a human has already drafted — improving clarity or structure. But the original technical approach and pricing must be human-created. If a team member asks, "Can I just have ChatGPT write the management approach section?" the answer is no — AI can polish, but humans create the original content. + +### Risk Assessment for New AI + +Every new AI application requires a **risk assessment** guided by the **NIST AI Risk Management Framework**: + +- Evaluate the tool's data handling practices +- Assess the risk of AI-generated errors in the intended use case +- Consider the impact if the AI tool's output is wrong + +This assessment is part of the CTO approval process. + +### Module E Quiz + +A team lead wants to use a new AI tool to help with project planning. What approval is needed? + +- [( )] No approval — project planning is internal work +- [( )] Manager approval is sufficient +- [(X)] CTO approval is required for any new AI tool or significant new application +- [( )] The team lead can approve it themselves if it's free +*** + +**Correct!** All new AI tools and significant new applications require CTO approval, regardless of the use case or cost. This ensures a proper risk assessment is conducted and the tool meets CivicActions' security standards. On client projects, client approval is also needed. + +*** + +## Bonus Quiz + +You've completed all five modules — great work! Here's a final question on a key governance concept. + +During a quarterly access review, you discover that a former contractor still has active access to a CivicActions system. Their contract ended two months ago. What should you do? + +- [( )] Leave it — they might come back for another contract +- [( )] Send them an email asking them to stop using the access +- [( )] Wait until the next quarterly review to confirm it should be removed +- [(X)] Revoke the access immediately and report it as a potential security finding +*** + +**Correct!** Orphaned access — permissions that belong to someone who no longer needs them — is a security risk and a common audit finding. Revoke it immediately. Don't wait, don't ask the person to self-manage, and don't assume they're not using it. The fact that it went undetected for two months is itself worth reporting so the access review process can be improved. + +*** + +## Course Complete + +Congratulations — you've finished **Access Governance, Risk & Supplier Oversight**! + +Here's what you covered: + +1. **Access governance** — approval role, access lifecycle (approve → grant → review → revoke), quarterly reviews, third-party access, CUI access decisions +2. **Risk management** — CIA matrix, 3×3 risk scale, treatment options, acceptance authority (System Owner → CISO → CEO), Risk Register and POA&Ms, annual review +3. **Supplier oversight** — three SCRM tracks (DS/S/PS), risk tiering, mandatory due diligence before procurement, required contract clauses, monitoring cadence, prohibited technologies +4. **Document control** — identification, classification, version control (major vs. minor), change request process, training coordination, annual review +5. **AI governance** — CTO approval for new tools, sales restrictions, risk assessment per NIST AI RMF + +**Remember the essentials:** + +- Least privilege and need-to-know guide every access decision +- Role changes, project transitions, and departures trigger immediate access reviews +- No supplier gets access without completed due diligence +- Risk acceptance must be explicit, recorded, and approved at the right authority level +- Controlled Documents are immutable — changes create new versions + +Questions? Reach out to **security@civicactions.com** or the Compliance team. diff --git a/README.md b/README.md index e69de29..1379a7a 100644 --- a/README.md +++ b/README.md @@ -0,0 +1,27 @@ +# CivicAction Training Program + +## Information Security Policies Training catalog + +| # | File | Title | Audience | Duration | +|---|------|-------|----------|----------| +| 1 | [CP-01-security-awareness-essentials](CP-01-security-awareness-essentials) | Security Awareness Essentials | All Staff | 30–45 min | +| 2 | [CP-02-cui-awareness-handling](CP-02-cui-awareness-handling) | CUI Awareness & Handling | Staff on federal/CUI contracts | 10–15 min | +| 3 | [CP-03-it-ops-change-config-patch](CP-03-it-ops-change-config-patch) | IT Operations: Change, Configuration & Patch Management | IT / Service Desk, Developers, System/Data Owners | 15–20 min | +| 4 | [CP-04-incident-response-responders](CP-04-incident-response-responders) | Incident Response for Responders | IT / SIRT members, Managers | 10–15 min | +| 5 | [CP-05-secure-dev-supply-chain](CP-05-secure-dev-supply-chain) | Secure Development & Supply Chain | Developers | 20–30 min | +| 6 | [CP-06-access-governance-risk-supplier](CP-06-access-governance-risk-supplier) | Access Governance, Risk & Supplier Oversight | Managers, System/Data Owners, Document Controllers | 25-30 min | + +### Who takes what + +| Role | Trainings | Est. total time | +|------|-----------|-----------------| +| General staff | 1 | ~45 min | +| Staff on CUI contracts | 1 + 2 | ~60 min | +| Developers | 1 + 3 + 5 | ~80 min | +| IT / Service Desk | 1 + 3 + 4 | ~70 min | +| SIRT members | 1 + 3 + 4 | ~70 min | +| Managers | 1 + 4 + 6 | ~90 min | +| System / Data Owners | 1 + 3 + 6 | ~80 min | +| Document Controllers | 1 + 6 | ~60 min | + +Add Training 2 (CUI) to any role working with federal CUI data.