Episode 49 — Identify Functions and Build a Security Concept of Operations That Holds Up
In this episode, we focus on a practical step that sits between abstract security principles and real system design: identifying system functions and building a Security Concept of Operations, often shortened to Security Concept of Operations (C O N O P S). A concept of operations is a clear description of how a system is expected to work in real life, including who uses it, what they do with it, what the normal workflows look like, and what happens when something goes wrong. Adding the security perspective means you describe those same workflows with protection in mind, so security is not a separate add-on but part of how the system operates every day. Beginners sometimes think security planning is mainly about picking controls like encryption or logging, but controls only make sense when you know what functions exist and how those functions are used. If you do not identify functions clearly, you cannot decide who should be allowed to do what, what data is touched, where trust boundaries are, or what evidence should be recorded. The goal is to show you how functional thinking and a security-focused CONOPS create a design that holds up under change, pressure, and real-world usage, rather than collapsing the first time an assumption breaks.
Before we continue, a quick note: this audio course is a companion to our course companion books. The first book is about the exam and provides detailed information on how to pass it best. The second book is a Kindle-only eBook that contains 1,000 flashcards that can be used on your mobile device or Kindle. Check them both out at Cyber Author dot me, in the Bare Metal Study Guides Series.
To begin, it helps to clarify what we mean by functions in a system context. A function is not a piece of code or a screen; it is a capability the system provides, like registering a user, resetting a password, submitting a request, approving a request, viewing a record, exporting a report, or updating a configuration. Functions describe what the system does, not how it is implemented. This matters because security decisions are usually about what actions are permitted and under what conditions, and those decisions must map to functions. If you only think in terms of components, you might miss that a single component supports multiple functions with different risk levels. For example, a portal might support both viewing data and changing permissions, and those two functions should not be treated the same way. Identifying functions forces you to separate routine actions from high-impact actions and to think about the consequences of misuse. Once functions are clear, you can attach security requirements to them in a way that is understandable and testable.
Function identification also reveals what data is involved, because most functions touch data in some way. When a user registers, the system collects identity information. When a user views a record, the system retrieves and presents data. When a user exports a report, the system aggregates and moves data, which can change risk. When an administrator updates settings, the system changes behavior, which can affect security controls indirectly. Seeing these data touches helps you identify where confidentiality, integrity, and availability are at stake. It also helps you find hidden high-risk functions that are easy to overlook, such as bulk export, account recovery, or privilege assignment. Attackers often target these high-leverage functions because they provide more impact for less effort. A security-aware function list does not just say what features exist; it highlights where misuse would be especially harmful. That highlighting sets the stage for a CONOPS that treats high-risk functions with appropriate safeguards.
Now consider what a concept of operations provides beyond a list of functions. A function list tells you what the system can do, but a CONOPS tells you how the system is used and how functions flow together in real workflows. For example, a user might create an account, verify identity, enroll in a service, submit information, and then view results later. An administrator might onboard a new organization unit, assign roles, review logs, respond to anomalies, and retire accounts. A CONOPS explains the sequence and purpose of these steps, which makes it possible to design security controls that fit natural usage rather than fighting it. If security controls disrupt the workflow without justification, people will work around them, which creates uncontrolled risk. If security controls align with workflow, they become part of normal operation and are more likely to be followed consistently. A strong CONOPS also documents what normal looks like, which is essential for monitoring, because you cannot detect abnormal behavior if you do not know what normal behavior is supposed to be.
A Security CONOPS adds specific security expectations to those workflows. It describes how identity is established, how access is granted, how privileges are used, and how actions are recorded. It also describes how the system behaves when security-relevant events occur, such as repeated failed logins, suspicious access patterns, or attempted actions that violate policy. Instead of treating these events as edge cases, the Security CONOPS treats them as normal operational realities that the system must handle gracefully. This is what it means for a CONOPS to hold up: it should not assume perfect users, perfect networks, or perfect components. It should anticipate mistakes, failures, and attacks, and it should describe how the system maintains safety under those conditions. A Security CONOPS is therefore both a design guide and a resilience guide, because it describes not only the happy path but also safe behavior on the unhappy path. For beginners, the key takeaway is that security planning becomes far more practical when it is expressed as operational behavior rather than abstract rules.
An important step in building a Security CONOPS is identifying actors and their roles, because operations are performed by someone or something. Actors include end users, administrators, support staff, automated services, and external systems that integrate with yours. Each actor interacts with functions differently, and each actor has different trust and risk characteristics. For example, an automated service might need consistent access to a narrow set of functions, while a support role might need the ability to assist users but should not have broad access to sensitive data. A Security CONOPS describes what each actor is supposed to do, what they are not supposed to do, and what checks exist to keep boundaries intact. It also clarifies where separation of duties is needed, such as ensuring that the same actor cannot both request and approve high-impact changes. When actor responsibilities are explicit, permissions can be designed to match them, which supports least privilege. Without explicit actor definitions, permissions tend to become messy bundles, which increases blast radius and makes incidents harder to contain.
Workflows also need security checkpoints, and a Security CONOPS is where you decide where those checkpoints belong. A checkpoint might be a point where identity is verified, where an approval is required, where a high-risk action is logged with extra detail, or where the system performs additional validation. If checkpoints are placed randomly, users experience them as annoying interruptions, and developers experience them as unpredictable constraints. If checkpoints are placed intentionally at points of high risk or high impact, they feel more reasonable and are easier to justify. For example, you might allow simple viewing actions after normal authentication, but require additional verification for actions like changing account recovery settings or exporting large datasets. You might allow routine updates with standard logging, but require more detailed audit trails for privilege changes. The Security CONOPS helps justify these choices by linking them to function risk, so the system’s behavior is consistent. Consistency is important because inconsistent security behavior confuses users and creates opportunities for attackers to find the weakest path.
A Security CONOPS that holds up also addresses operational maintenance, because systems are not static. Accounts are created and removed, permissions change, data retention rules evolve, and software is updated. If your security story only covers initial deployment, it will fail over time as the system drifts away from the assumed state. A resilient Security CONOPS includes how updates happen, how access is reviewed, how keys or secrets are managed, how backups are handled, and how recovery is performed after incidents. It also addresses how exceptions are handled, because real life includes unusual cases, and unmanaged exceptions become permanent holes. By describing exception handling, such as how temporary access is granted and removed, you reduce the chance that emergency actions undermine long-term security. For beginners, this is an important lesson: security is not just a build-time concern, it is an operate-time concern. A CONOPS is where you define secure operation as a continuous practice rather than a one-time achievement.
Another reason a Security CONOPS matters is that it supports communication among different groups. Developers need to understand expected security behaviors so they can implement them correctly. Operators need to understand expected workflows so they can monitor and respond effectively. Stakeholders need to understand the rationale for controls so they can support them and not pressure teams to remove them without understanding consequences. A well-written Security CONOPS acts like a shared reference, reducing the chance that each group invents its own mental model of how the system works. This is especially critical during incidents, when stress and time pressure can cause misunderstandings. If responders know the expected behavior, they can recognize deviations faster and choose containment actions with more confidence. A Security CONOPS also helps onboard new team members, reducing human single points of failure. In short, it makes the system’s security posture teachable, and teachable systems are easier to keep secure.
A common misconception is that building a CONOPS is only useful for large, formal projects, but even small systems benefit because unclear operations create unclear security. If you cannot describe how a user recovers an account safely, that is an operational gap that attackers can exploit. If you cannot describe how administrative changes are approved, that is a governance gap that can lead to misuse or errors. If you cannot describe what logging should capture for high-risk functions, then monitoring becomes guesswork. A Security CONOPS does not have to be long to be useful, but it does need to be honest and specific about how the system will be used. It should also be written in a way that survives changes, meaning it focuses on behaviors and responsibilities rather than tool-specific steps. Tools will change, but the need to verify identity, enforce permissions, and maintain accountability will not. When the CONOPS focuses on durable concepts, it remains useful even as implementations evolve.
As we conclude, remember that identifying functions and building a Security Concept of Operations is about grounding security in real system behavior. Functions tell you what the system can do, which lets you classify actions by risk and decide where controls must be strict. A Security CONOPS tells you how those functions are used in real workflows, which lets you design security so it fits normal operation and remains safe under abnormal conditions. When done well, it reduces attack surface by limiting unnecessary capabilities, reduces blast radius by separating responsibilities, and improves resiliency by defining safe behavior during failures and incidents. It also makes security easier to communicate, maintain, and validate over time, which is what it means for it to hold up. For a beginner, the key habit is to translate security from abstract rules into operational questions like who performs this action, under what conditions, touching what data, and what evidence should be recorded. When you can answer those questions clearly, you are building the kind of security story that can survive real-world stress rather than falling apart the first time something unexpected happens.
