CYOP 360 at the University of Maryland Global Campus looks at security across the whole software development process, not just in the code.
UMGC describes it as an in-depth study of the processes, standards and regulations associated with secure software engineering. The objective is to plan, manage, document and communicate all phases of a secure software development cycle.
Topics include security requirements, secure software life cycle development, threat modeling, and Security Technical Implementation Guides (STIGs). The course was formerly SDEV 360 (credit for only one), and the prerequisite is CMSC 215 or CYOP 200.
Much of the work is documentation, which surprises students who expected mostly coding. Clear, traceable documents are exactly what secure engineering depends on.
Course at a Glance
| Item | Details |
|---|---|
| University | University of Maryland Global Campus (UMGC) |
| Course code | CYOP 360 (formerly SDEV 360) |
| Level | Undergraduate, 3 credits |
| Prerequisite | CMSC 215 or CYOP 200 |
| Subject area | Secure software engineering |
| Typical work | Security requirements, threat models, life cycle plans, STIG reviews |
What CYOP 360 Covers
| Topic | In plain language |
|---|---|
| Security requirements | Statements of what the software must do, or never do, to stay secure |
| Secure development life cycle | Building security into every phase, from planning to maintenance |
| Threat modeling | Identifying how a system could be attacked, early in design |
| STIGs | Detailed configuration standards from the US Defense Information Systems Agency (DISA) |
| Standards and regulations | External rules that shape how software must be built |
| Communication | Documenting and explaining security to teams and managers |
Key Concepts Explained
Writing Testable Security Requirements
A good security requirement is specific and testable. "The system shall be secure" cannot be tested; "the system shall lock an account for 15 minutes after five failed login attempts" can.
Threat Modeling with STRIDE
STRIDE is a widely used model that groups threats into six types: Spoofing, Tampering, Repudiation, Information disclosure, Denial of service and Elevation of privilege. Apply it to each part of a data flow diagram.
Example: A student portal has a login form, an API and a grades database. Spoofing: stolen passwords used to log in, so require multi-factor authentication. Tampering: grade values altered in transit, so use TLS and server-side validation. Repudiation: a staff member denies changing a grade, so log every change with user and time. Elevation of privilege: a student calls an admin API, so enforce authorization checks on every endpoint. Each threat becomes a requirement and a test.
Security in Every Phase
Secure life cycle models, such as the NIST Secure Software Development Framework (SP 800-218), place activities across phases: requirements and threat modeling in planning, secure design reviews, secure coding and analysis during build, security testing before release, and patching and monitoring after.
Working with STIGs
STIGs are checklists of secure configuration settings for specific products, such as operating systems, databases and web servers. They are mandatory for US Department of Defense systems and widely used elsewhere as a benchmark.
In assignments, a STIG review usually means comparing a system's settings against the relevant guide and reporting gaps. For each gap, record:
- the STIG rule and its severity category;
- the current setting and the required setting;
- the risk if left unfixed;
- the fix, or a justified exception.
Typical Assignments and How to Approach Them
| Assignment type | What it tests | How to approach it |
|---|---|---|
| Security requirements document | Clear, testable requirements | Link each requirement to a threat or regulation |
| Threat model | Systematic threat identification | Diagram, then STRIDE per element |
| Life cycle plan | Managing security across phases | Activities, owners and outputs per phase |
| STIG compliance review | Applying configuration standards | Rule, finding, risk, fix |
Where Students Get Stuck
- Untestable requirements. Add numbers, conditions and actions.
- Threat lists without a diagram. Model the system first, then the threats.
- No traceability. Link threats to requirements to tests.
- Security only at the end. Show activities in every phase.
Study Tips for CYOP 360
- Practice drawing simple data flow diagrams with trust boundaries.
- Keep a STRIDE prompt card handy for every design task.
- Browse a STIG for a product you know to see how rules are written.
- Use a traceability table in every major submission.
How We Help with CYOP 360
Send the assignment brief, system description or design, the rubric and feedback. A writer with software security background can tutor you through threat modeling, prepare model documentation for reference, or review your requirements and plans.
GradeEssays is independent of the University of Maryland Global Campus. Use our work as a learning aid and submit your own under UMGC's academic integrity policy. Every order is written from scratch, with free revisions within the scope of your original request.
Document Your CYOP 360 Project with Confidence
Share the assignment, design and rubric. A security writer prepares model documentation you can study.
Start My CYOP 360 HelpFree revisions · Full refund if late · Written from scratch for your order
Frequently Asked Questions
CYOP 360 was formerly SDEV 360, and UMGC allows credit for only one.
UMGC lists CMSC 215 or CYOP 200.
A Security Technical Implementation Guide: a detailed secure configuration standard published by DISA.
A threat modeling method covering spoofing, tampering, repudiation, information disclosure, denial of service and elevation of privilege.
UMGC's description focuses on planning, managing, documenting and communicating a secure development cycle, so expect substantial documentation.
No. We offer tutoring, model documents for reference and editing of your own work.