Certified: The GIAC GCCC Audio Course

In this episode, we establish software authority so only trusted tools run and your environment does not quietly become a collection of random executables held together by hope. Software is one of the fastest ways to introduce risk because it is easy to install, easy to hide, and often difficult to fully understand once it spreads. If you do not have a clear authority model, you will struggle to answer basic questions during audits and incidents, such as which applications are allowed, who approved them, what versions exist, and how you know they are still safe and supported. Software authority is not just a security preference; it is a governance expectation that supports licensing compliance, vulnerability management, and response readiness. This is also where the CIS Controls mindset becomes practical because it pushes you toward repeatable decisions and evidence rather than informal exceptions. The objective here is not to ban everything or slow teams down unnecessarily. The objective is to build a system that lets the business move while keeping software risk visible and controlled.

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.

Start by defining software inventory scope, because you cannot govern what you refuse to count. Installed applications are the obvious category, and these are typically visible through endpoint management, package managers, and standard inventory tools. Portable applications are less obvious because they can run from user directories or removable media without traditional installation steps, and they are a common path for bypassing controls. Cloud applications add a different dimension because the software is not installed locally but still processes enterprise data and authenticates users, often through single sign-on. Your scope should also include browser extensions and productivity add-ons when they can access sensitive data or influence authentication flows, because these often encode significant permissions. Defining scope means deciding what you will track, how you will detect it, and what evidence counts as proof of presence or use. If you omit a category, you are not just simplifying; you are choosing a blind spot. A mature authority model acknowledges these categories explicitly and assigns control points that match how each type of software enters and operates.

Once scope is defined, build an approved software list with business justification, because approval without justification turns into politics and inconsistency. The approved list is not merely a catalog of things people like; it is a decision record that explains why a tool is needed, what it is used for, and what risks were considered. Business justification can be as simple as the capability the software provides, the business unit that owns the use case, and the expected user population. Security justification includes whether the vendor is reputable, whether the product has a clear update path, and whether it can be monitored or constrained appropriately. Operational justification includes whether support teams can manage it, whether deployment is feasible, and whether it creates dependencies that will be painful later. An approved list also needs to be organized in a way that helps control decisions, such as grouping by function, criticality, and environment. When the list has justification, approvals become defendable, and when approvals are defendable, governance becomes stable.

Licensing realities must be addressed early, because licensing is where many organizations discover that their software authority model is not real. Entitlement proof matters because the organization needs to show it has the right to use the software it runs, and entitlement often changes with renewals, contract terms, and vendor audits. Renewals also create operational risk because a lapsed license can disrupt business operations, and a rushed renewal can force unreviewed terms that affect security, privacy, or audit rights. Licensing audits are not just a legal concern; they can expose unmanaged installations, shadow usage, and gaps in procurement controls. If you treat licensing as separate from security governance, you will end up with parallel systems that disagree, and disagreements create both cost and risk. A mature approach ties licensing status to the approved list so that approval includes who pays, what the renewal cycle is, and who is accountable for managing the relationship. When entitlement, renewal, and audit readiness are part of approval, software authority supports both security outcomes and financial governance.

To make governance operational, practice classifying software as approved, tolerated, or prohibited, because not every decision needs to be binary and classification helps you manage reality. Approved software is explicitly allowed and supported, with known deployment paths and clear ownership. Tolerated software is not formally approved but is allowed temporarily under constraints, often because it is low risk, widely needed, or difficult to eliminate quickly without disrupting work. Prohibited software is disallowed because it presents unacceptable risk, violates licensing terms, conflicts with policy, or undermines security controls. Classification should be tied to criteria that reflect risk and operational impact, such as data access, network behavior, update mechanism, vendor trust, and ability to monitor and control execution. The tolerated category is especially important because it acknowledges that real environments include transitional states, but it must be time-bound to avoid becoming permanent loophole territory. When you can classify cleanly, you can respond to new software sightings consistently rather than improvising under pressure. This also supports incident response, because prohibited software sightings become higher priority signals.

As you enforce software authority, avoid pitfalls like unmanaged plugins, bundled tools, and shadow installers, because these are common ways software enters without anyone noticing. Unmanaged plugins include browser extensions, office add-ins, and integration connectors that quietly gain access to sensitive data and identity flows. Bundled tools arrive when legitimate installers include extra components, toolbars, agents, or utilities that are not part of the approved decision and may have their own vulnerabilities. Shadow installers are tools that users bring in through personal downloads, portable executables, or peer-to-peer sharing, often because they are trying to solve a problem quickly. Another pitfall is focusing only on the primary application name while ignoring the publisher, the updater, and the auxiliary services installed alongside it. These extras can create persistence mechanisms and network communication paths that are not captured in simplistic inventory reports. If you ignore these entry routes, your approved list will look clean while your endpoints accumulate ungoverned components. The remedy is making scope and detection cover these categories and making approval criteria include them explicitly.

A quick win that reduces chaos is using a single intake process for software requests, because multiple informal request paths are how bypasses become normal. Intake does not need to be heavy; it needs to be consistent and discoverable so teams know where to go when they need something. A single intake process also centralizes the record of why software was requested, who requested it, what business need it serves, and what review occurred. This becomes valuable evidence during audits, because you can show that software decisions are governed rather than random. It also prevents the social pattern where the fastest path is to ask a friend for an installer or to find a workaround, which undermines both security and licensing controls. If the intake process is too slow, it will be bypassed, so the design must balance review rigor with responsiveness. A good intake process includes a clear path for urgent requests, which we will discuss in a moment, because urgency is where most governance systems break.

Now identify control points like packaging, deployment, execution, and procurement, because authority is enforced through control points, not through lists. Packaging is where software is prepared for use, such as building managed packages, signing components, and ensuring configurations are set to safe defaults. Deployment is where software reaches endpoints or environments, such as through endpoint management systems, software distribution tools, or cloud marketplace processes. Execution is where the rubber meets the road, because an application is only governed if you can restrict what runs, from where, and under what identity context. Procurement is where the organization controls purchasing and licensing, ensuring entitlement is tied to approval and that vendor risk is reviewed before spend. Each control point can prevent different classes of failure, and the best programs use multiple control points so a single miss does not become a compromise pathway. If you only control procurement but not execution, unauthorized software can still run, and if you only control execution but not procurement, licensing and vendor risk will still be unmanaged. Authority becomes real when control points align to scope and classification decisions consistently.

Because business reality includes urgency, mentally rehearse handling urgent software needs without bypasses, because urgency is when shadow installers and risky exceptions spread fastest. An urgent need might be a critical patch tool, a client requirement for a specific viewer, or a temporary utility needed to restore business operations. The wrong outcome is a bypass that becomes a precedent, because bypasses teach the organization that governance is optional when pressure is high. The right outcome is a defined fast path that still captures approval intent, records justification, and applies constraints appropriate to the risk. Constraints might include limited user scope, time-bound approval, restricted data access, and additional monitoring while the software is in use. You also need a follow-up step that either formalizes approval with full review or removes the software when the urgent need passes. Rehearsal helps because when the urgent request arrives, you want to respond with a known process rather than inventing a workaround that you later regret. Calm, structured urgency handling builds trust, because teams see governance as enabling rather than blocking.

To keep the model simple, create a memory anchor: approve, track, deploy, verify, retire. Approve means the software is evaluated, classified, and justified, with clear ownership and licensing alignment. Track means the inventory reflects what is installed, what is used, and what versions exist, including portable and cloud application visibility when applicable. Deploy means software enters environments through controlled channels that enforce safe defaults and consistent configuration. Verify means you confirm that only authorized software is executing and that monitoring and update mechanisms are functioning as expected. Retire means software is removed when it is no longer needed, when it becomes unsupported, or when it fails security or licensing criteria. This anchor matters because many organizations stop at approve and deploy, then forget verification and retirement, which is how outdated tools linger for years. The full lifecycle is what keeps software authority stable over time. When you apply the anchor repeatedly, software governance becomes a loop rather than a one-time decision.

Track versions and publishers to reduce supply-chain surprises, because the risk profile of software changes with updates, acquisition events, and distribution channels. Version tracking is essential for vulnerability management, because you cannot assess exposure to a known issue if you do not know which versions exist. Publisher tracking is essential because the same product name can exist under different publishers, and attackers sometimes use lookalike names to blend in. You also want to track update mechanisms, because software that updates itself outside managed channels can introduce unexpected changes and can bypass validation steps. Supply-chain risk is not limited to malicious vendors; it includes compromised update infrastructure, dependency issues, and repackaged installers distributed through unofficial channels. When you track publisher and version, you gain the ability to quickly answer who is running what, where, and whether it is within approved and supported boundaries. This also improves incident response, because you can rapidly assess whether a compromised vendor event affects your environment. The discipline here is not paranoia, it is operational readiness.

Now do a mini-review and name three ways unauthorized software enters, because awareness of entry paths is what makes control point selection effective. One common path is user-driven installation from the internet, where convenience overrides policy and the organization has limited visibility unless execution controls exist. Another path is portable executables, where software runs without installation and bypasses traditional inventory mechanisms unless detection includes file execution telemetry. A third path is plugins and add-ons, where extensions, integration connectors, and embedded scripts introduce capabilities and access without going through procurement or software distribution channels. You could also add bundled components as a frequent source, where approved installers carry unapproved extras that persist. The point is that unauthorized software rarely enters through a single door, so your authority model must cover multiple entry routes. When you can name the routes, you can choose the control point that blocks the route with the least disruption. This is how you keep the program practical rather than theoretical.

With the entry paths in mind, choose one control point to tighten immediately, because a single well-chosen improvement can reduce risk quickly. Tightening might mean enforcing that software distribution happens only through managed packaging and deployment for certain endpoint categories. It might mean strengthening execution control policies for high-risk systems so only approved publishers or signed binaries can run. It might mean tightening procurement so new purchases require linkage to the approved list and owner assignment before a contract is signed. It could also mean improving plugin governance, such as restricting extension installation to approved items and monitoring for new add-ons with risky permissions. The right choice depends on where your unauthorized software is currently entering and where you can apply enforcement without breaking critical operations. The key is that tightening should produce a measurable change, such as fewer unauthorized installations, faster detection of drift, or improved license compliance. When you pick one control point and tighten it, you demonstrate that authority is operational, not aspirational.

To conclude, establishing software asset authority means defining scope across installed, portable, and cloud applications, then building an approved list grounded in business justification and enforceable criteria. Licensing realities must be integrated into governance through entitlement proof, renewal ownership, and audit readiness, because software authority fails when procurement and usage drift apart. Classification into approved, tolerated, and prohibited supports practical decision making, while awareness of pitfalls like unmanaged plugins, bundled tools, and shadow installers prevents your program from being bypassed through side doors. Authority is enforced at control points such as packaging, deployment, execution, and procurement, and urgent needs must be handled through a fast path that records justification and maintains constraints. The memory anchor approve, track, deploy, verify, retire keeps the lifecycle complete so outdated and unmanaged software does not linger indefinitely. Now document your approval criteria clearly, because criteria are what make decisions consistent, defensible, and repeatable across teams and over time.