Security Engineering: Asset Evaluation and Execution Plan

Table of Contents

• Module 1: Understanding the Security Engineer Landscape
  • The Role of a Security Engineer
  • Security Engineering Challenges and Pillars
  • Aligning Security Engineering with Business Objectives
• Module 2: Demonstrating Asset Inventory and Management
  • The Purpose of Asset Management
  • Identifying and Classifying IT Assets
  • Approaches to Asset Management
  • Demo: Managing Assets Using Lansweeper
• Module 3: Creating a Security Engineering Execution Plan
  • Defining Processes and Procedures
  • Strategy for an Execution Plan
  • Meeting with Leadership
• Module 4: Continuing and Next Steps
  • Communication and Reporting
  • Execution and Next Steps
• Summary

This course explores the role of the security engineer, beginning with a comprehensive approach to asset inventory, moving into identifying and managing IT assets, and finishing with crafting actionable execution plans to secure those assets. A running case study — Globomantics, an organization that has just acquired several small defense-manufacturing firms — is used throughout to ground each concept in a realistic, end-to-end scenario: from understanding what a security engineer does, to inventorying the newly acquired IT estate, to building and presenting a plan that secures it.

Module 1: Understanding the Security Engineer Landscape

The Role of a Security Engineer

The role of a security engineer centers on three major tasks as they relate to security tools, solutions, and controls:

1. Designing a solution — figuring out the necessary components and requirements so the solution can be implemented into the environment.
2. Implementing that solution — integrating it into existing architecture, which is rarely as simple as “set it up and forget it,” especially in large, complex enterprise environments with many interdependent components.
3. Maintaining the solution — ensuring it continues to function as intended and continues to provide value in the form of security protection or performance enhancement.

Where the Security Engineer Fits

A typical organization’s technical cybersecurity talent can be viewed as a tiered structure:

flowchart TB
    A["Security Architect<br/>Provides the blueprints for the organization's<br/>overall security architecture (high-level design)"]
    B["Security Engineer<br/>Provides detailed design and implements the<br/>solutions referenced in the architect's blueprints"]
    C["Security Analyst<br/>Monitors SIEM alerts, investigates security events,<br/>and performs incident response"]

    A --> B --> C

    style A fill:#4a6fa5,color:#fff
    style B fill:#5b8c5a,color:#fff
    style C fill:#c96f3c,color:#fff

• The security architect operates at the highest level, focused on the overarching design and placement of security solutions.
• The security engineer operates one tier below the architect, providing much more detailed design and actually implementing the solutions referenced in the architect’s blueprints — for example, selecting an identity and access management (IAM) platform such as Okta for authenticating identities and enabling single sign-on.
• The security analyst sits at the lower tier, leveraging the tools and controls that engineers build and maintain — monitoring SIEM alerts, querying logs during investigations, and performing incident response (e.g., mitigating a phishing campaign or remediating malware on a server or endpoint).

In short: the architect lays the foundation for the organization’s overall security architecture and planning; security engineers design, implement, and maintain the various security controls, tools, and solutions; and security analysts leverage those controls to perform their day-to-day tasks such as event investigation and incident response.

Security Engineer Specializations

The security engineer role can be broken down into a wide range of specializations:

mindmap
  root((Security Engineer<br/>Specializations))
    IAM
      Authentication
      Single sign-on
      Access control
    Network Security
      Firewalls
      Wireless access points
      Switch/router security
    SIEM
      Dashboards
      Alerting
    Physical Security
      Locks
      Access mechanisms
    Application Security
      WAF
      Code vulnerability remediation
    Cloud Security
      IAM in the cloud
      Cloud firewalls
    AI Security
      IAM for AI platforms
      VPC configuration
    Tool Development
      Custom scripts
      Automation for analysts

Career Paths

Security engineering specializations primarily cater to a technical career path. With enough experience, an engineer can transition to a higher technical role such as security architect. However, security engineers are not limited to technical roles — many eventually transition to a non-technical path centered on Governance, Risk, and Compliance (GRC).

flowchart LR
    SE["Security Engineer<br/>(IAM / Network / Cloud / App / AI / SIEM)"]
    SE -->|Technical path| SA["Security Architect"]
    SE -->|Non-technical path| GRC["Governance, Risk, and Compliance"]
    SA --> Lead["Leadership<br/>(CISO / CIO / CTO)"]
    GRC --> Lead

    style SE fill:#4a6fa5,color:#fff
    style Lead fill:#c96f3c,color:#fff

A strong technical background aids either path. GRC roles, in particular, tend to interface with management and executives far more frequently than purely technical roles, and that added visibility can be leveraged toward consideration for a leadership role such as Chief Information Security Officer (CISO), Chief Information Officer (CIO), or Chief Technology Officer (CTO) — among the highest-compensated roles in enterprise organizations internationally. This is not to say a technical architect role cannot lead to leadership; it simply highlights that non-technical GRC roles traditionally provide more direct executive interfacing.

Security Engineering Challenges and Pillars

Challenges Facing Security Engineers

flowchart TD
    C["Security Engineering Challenges"]
    C --> T["Threat Actors & Attack Surface<br/>Hackers seeking monetary gain via data theft or ransomware"]
    C --> Comp["Compliance<br/>Legal regulations and industry standards"]
    C --> D["Deployment Issues<br/>Real-world implementations are rarely as simple as they seem"]
    C --> U["End-user Satisfaction<br/>Users may circumvent solutions they dislike"]

    style C fill:#4a6fa5,color:#fff

• Threat actors and attack surface — Hackers seek to steal sensitive information or deploy ransomware for monetary gain. To combat this, it is critical to understand the organization’s attack surface and maintain visibility across assets, platforms, tooling, solutions, and vendors. Simply put: you cannot defend against what you cannot see or have no information about.
• Compliance — Remaining compliant avoids legal ramifications and financial penalties, and keeps the business operational by adhering to legal regulations and industry standards.
• Deployment issues — Security solutions do not deploy overnight and often run into implementation issues; simple-looking deployments are rarely simple in reality.
• End-user satisfaction — Solutions must be both functional/secure and acceptable to end users. If users are unhappy with a solution, they are more likely to circumvent it while doing their job. For example, an IAM engineer might favor passwordless authentication (e.g., a push notification to a user’s mobile device via Microsoft Entra ID) over requiring users to carry easily lost hardware token-generation devices — sometimes less is more.

The Pillars of Security Engineering

Most security professionals are familiar with the CIA triad — Confidentiality, Integrity, and Availability. As a security engineer, it is your responsibility to adhere to secure design in order to support that triad.

flowchart TD
    CIA["CIA Triad<br/>Confidentiality • Integrity • Availability"]
    SD["Secure Design<br/>Security from the start — account for<br/>vulnerabilities and misconfigurations early"]
    P["Prevention<br/>Firewalls and IAM access controls<br/>block malicious requests"]
    Det["Detection<br/>Alarms notify the appropriate team members<br/>when malicious activity is detected"]
    R["Response<br/>Analysts and incident responders act<br/>on detected activity"]

    SD --> CIA
    CIA --> P
    P --> Det
    Det --> R
    R -.supports.-> IR["NIST SP 800-61:<br/>Computer Security Incident Handling Guide"]

    style CIA fill:#4a6fa5,color:#fff
    style IR fill:#c96f3c,color:#fff

These pillars directly support the incident response lifecycle described by NIST in the Computer Security Incident Handling Guide (NIST Special Publication 800-61). This holistic perspective is especially valuable for security engineers responsible for developing tooling used by other members of the security team.

Aligning Security Engineering with Business Objectives

Objectives, Goals, and Mission

flowchart TD
    O["Objectives<br/>Small, measurable, specific achievements<br/>completed in weeks or months<br/>(e.g., deploy a WAF, provision a database)"]
    G["Goals<br/>Larger achievements taking months to years<br/>(e.g., 5-10 goals set at the start of a year)"]
    M["Mission<br/>Multi-year vision based on the organization's<br/>values, culture, and purpose"]

    O --> G --> M

    style O fill:#5b8c5a,color:#fff
    style G fill:#4a6fa5,color:#fff
    style M fill:#c96f3c,color:#fff

• Objectives are small, measurable, specific achievements — for example, deploying a web application firewall, deploying the databases that support a web application, and provisioning the resources/services necessary to support it. These are typically achievable within weeks or months.
• Goals may take several months to years to achieve. Organizations commonly start the year with 5 to 10 goals. Objectives feed into goals — e.g., all those web-application-related objectives feed into the goal of launching a new web application. Departments outside of IT (such as marketing) also have their own business objectives (e.g., launching a new campaign) that feed into broader goals.
• Mission is a multi-year vision grounded in the organization’s values, culture, and purpose (e.g., a university’s mission of providing educational services to learners seeking degrees and certifications).

Case Study: Aligning to Globomantics’ Acquisition Objective

Globomantics recently completed the business objective of acquiring several small firms, feeding into their annual goal of becoming more competitive in the defense industry by acquiring firms that specialize in defense manufacturing and hold valuable R&D insights.

flowchart LR
    Obj["Objective:<br/>Acquire small defense-manufacturing firms"] --> Goal["Goal:<br/>Become more competitive<br/>in the defense industry"]
    Goal --> Mission["Mission:<br/>Sell innovative products"]

    Obj --> SE1["Security Engineer Action:<br/>Perform asset inventory & evaluation"]
    SE1 --> SE2["Understand attack surface<br/>and exposure of new assets"]
    SE2 --> SE3["Assess risk associated<br/>with these assets"]
    SE3 --> SE4["Design, implement, and maintain<br/>security controls"]

    style Obj fill:#5b8c5a,color:#fff
    style Goal fill:#4a6fa5,color:#fff
    style Mission fill:#c96f3c,color:#fff

Security engineers align to this business objective by first performing asset inventory and evaluation on the newly acquired firms. This feeds directly into understanding the attack surface and exposure of those new assets, which in turn feeds into risk assessment and, ultimately, the design, implementation, and maintenance of the security controls that protect those assets.

Risk and Risk Management

Risk is the likelihood that a threat will cause an undesirable incident — such as a ransomware attack, sensitive data exfiltration, or a denial-of-service attack that takes services offline for an extended period. Any of these can seriously affect the organization financially, potentially putting it out of business. For this reason, organizations calculate and assess risk through a process known as risk management.

For security engineers, risk analysis — and quantitative risk analysis in particular — drives which business objectives are undertaken and prioritizes which objectives must be completed first.

Quantitative Risk Analysis: The Math Behind ALE

ALE is important to security engineers because it aligns directly with a business objective like the Globomantics acquisitions: the only way to calculate ALE — which ultimately helps leadership understand the expected annual loss — is through asset value and exposure factor, both of which are directly tied to the security engineer’s work of asset inventory and evaluation.

Residual risk calculations help the organization understand the risk still facing an asset after controls have been implemented. This drives future design and implementation decisions, especially if the organization is unsatisfied with the amount of residual risk that remains.

flowchart TD
    AI["Asset Inventory & Evaluation"] --> AV["Determine Asset Value (AV)"]
    AI --> EF["Determine Exposure Factor (EF)"]
    AV --> SLE["Single Loss Expectancy<br/>SLE = AV x EF"]
    EF --> SLE
    SLE --> ARO["Apply Annualized Rate<br/>of Occurrence (ARO)"]
    ARO --> ALE["Annual Loss Expectancy<br/>ALE = SLE x ARO"]
    ALE --> Prioritize["Prioritize security objectives<br/>by risk reduction value"]
    Prioritize --> Controls["Design / Implement / Maintain<br/>security controls"]
    Controls --> RR["Residual Risk<br/>(risk remaining after controls)"]
    RR -.re-evaluate.-> Prioritize

    style ALE fill:#c96f3c,color:#fff

Two guiding principles when selecting and implementing security controls:

• The cost of the control should never exceed the value of the asset it protects — you would never use a $1,000 door lock to protect an asset worth only $5.
• Controls require ongoing maintenance; a lack of maintenance can render a control ineffective.
• Controls should demonstrate measurable risk-reduction value — a control that reduces ALE by 10% is more valuable than one that only reduces it by 5%.

Module 1 Recap

• Security engineers design, implement, and maintain security tools, solutions, and controls, and can specialize across IAM, network, SIEM, physical, application, cloud, and AI security, as well as security tool development.
• Security engineering careers can follow a technical path (toward security architect) or a non-technical GRC path, both of which can lead to leadership roles such as CISO, CIO, or CTO.
• Key challenges include understanding threat actors and the attack surface, maintaining compliance, managing deployment friction, and preserving end-user satisfaction.
• The pillars of security engineering — secure design, prevention, and detection — support the CIA triad and the NIST SP 800-61 incident response lifecycle.
• Business objectives are small, measurable achievements that feed into larger goals, which in turn support the organization’s overarching mission. Security engineers align to these objectives through asset inventory, evaluation, and risk-driven control implementation.
• Quantitative risk analysis (ALE = SLE × ARO = AV × EF × ARO) and residual risk drive which security controls are selected, prioritized, and refined.

Module 2: Demonstrating Asset Inventory and Management

The Purpose of Asset Management

Following on from the Globomantics acquisition scenario, security engineers are tasked with understanding the assets acquired, their exposure level, and the security controls needed to protect them. IT asset management includes:

• Tracking the number and location of assets.
• Identifying the various types of assets acquired.
• Monitoring asset health and utilization.
• Maintaining assets through patching, upgrades, and/or repairs.

The Three Asset Types

flowchart TD
    AM["IT Asset Management"] --> Infra["Infrastructure & Hardware<br/>Servers, workstations, equipment"]
    AM --> Soft["Software<br/>Licenses used by workloads and end users"]
    AM --> Data["Data<br/>Sensitive/meaningful business data"]

    style AM fill:#4a6fa5,color:#fff

Why Asset Management Matters

flowchart LR
    V["Visibility<br/>What assets exist, how many, where they are"]
    V --> RA["Risk Analysis"]
    V --> VM["Vulnerability Management<br/>(identify CVEs tied to model/version)"]
    V --> Val["Monetary Valuation<br/>(determine appropriate control cost)"]
    V --> Comp["Compliance"]

    style V fill:#4a6fa5,color:#fff

• Visibility — Knowing what assets exist, how many, and where they’re located enables meaningful risk analysis.
• Vulnerability management — Visibility allows the organization to identify common vulnerabilities and exposures (CVEs) tied to a given asset’s model or version.
• Monetary valuation — Understanding the monetary value of assets lets security engineers determine an appropriately priced control. As before: never use a $1,000 door lock to protect a $50 asset.
• Compliance — One of the most important aspects of asset management. Compliance comes in multiple forms:

This is only the surface of the available compliance frameworks, standards, and regulations. Failure to meet compliance can result in legal action and financial penalties, and non-compliance can also restrict business operations — adding further financial burden. Security engineers must prioritize compliance when designing security controls and solutions.

Identifying and Classifying IT Assets

Infrastructure and Hardware Assets

Infrastructure assets include end-user desktops, notebooks, tablets, and mobile devices — typically managed via an agent that reports health, location, and status to a central management console. Servers and network devices are usually top-of-mind, being among the most valuable and expensive hardware assets, but it’s important to remember that VoIP phones and printers are part of the infrastructure too. Though seemingly innocuous, these devices can serve as attack points — an insider threat recording voice calls, or an attacker exfiltrating scanned documents from a compromised printer.

Assets can also be virtual (virtual machines and virtual servers), and one of the most difficult categories to identify is Internet of Things (IoT) devices — wireless cameras, sensors, appliances, and other devices leveraging mobile computing power with an internet connection. Although sometimes overlooked, IoT devices are IT assets with real exposure factor, especially since their firmware is often out of date, leaving them vulnerable to exploitation as an entry point or for side-channel communication.

Software Assets

Software assets include desktop software requiring a legally purchased license (e.g., Adobe Photoshop) as well as software increasingly delivered exclusively as Software as a Service (SaaS) (e.g., Microsoft 365). Asset management extends to server-based licensing, virtual server licensing, and end-user operating system licensing. Adequate license tracking helps avoid fines related to software license auditing.

Data Assets

Data is the most critical — and most intangible — asset type:

• Personally Identifiable Information (PII) — social security numbers, phone numbers, addresses, and any information that can uniquely identify a person (customer data and employee data alike). Failure to protect PII can result in legal action and fines, so it must be protected using access controls, encryption, and other security controls.
• Sensitive internal data — internal secrets related to intellectual property, supply chain and manufacturing details that give the company a competitive edge. Losing control of this data can cause the organization to lose its competitive edge and damage perception among customers and partners. This category also includes market-research data and financial data sensitive to business operations.

mindmap
  root((Asset Types))
    Infrastructure/Hardware
      Desktops, notebooks, mobile devices
      Servers & network devices
      VoIP phones & printers
      Virtual machines/servers
      IoT devices
    Software
      Desktop software licenses
      SaaS subscriptions
      Server/OS licensing
    Data
      PII (customer & employee)
      Intellectual property
      Supply chain/manufacturing secrets
      Market research & financial data

Methods for Identifying Each Asset Type

Automated infrastructure discovery provides control and visibility into which assets are active and how utilized they are — useful when an organization is looking to reduce costs by disposing of underutilized assets. These are only a few examples; thorough research should guide selection of the solution that best fits the organization.

Approaches to Asset Management

Two contrasting approaches define how much information you have about your assets:

flowchart LR
    BB["Black-box Approach<br/>Limited visibility<br/>Detailed information is lacking"]
    WB["White-box Approach<br/>Extensive visibility<br/>Complete information available"]

    BB -->|Simpler, but leaves uncertainty| Risk1["Estimations must be made about<br/>asset count, location, and risk"]
    WB -->|More complex, but comprehensive| Risk2["Enables identification of<br/>potential security concerns"]

    style BB fill:#c96f3c,color:#fff
    style WB fill:#5b8c5a,color:#fff

In the Globomantics scenario, the security engineering team is currently operating with a black-box approach toward the newly acquired assets, having little to no detailed information available. In the real world, most organizations fall somewhere between the two extremes, and the amount of information available is often dictated by the type of environment the assets live in.

Asset Environments

flowchart TD
    Env["Asset Environment"] --> OnPrem["On-premises<br/>Physical control over location<br/>Detailed model/serial info<br/>Locked doors & access-card control"]
    Env --> Cloud["Cloud<br/>Physically located at the CSP's data center<br/>Managed via console or CLI/credentials"]
    Env --> Hybrid["Hybrid<br/>Some assets on-prem, some in the cloud<br/>No single tool centrally manages everything"]
    Env --> IoT["IoT<br/>Billions of connected devices<br/>Requires dedicated centralized IoT management"]

    style Env fill:#4a6fa5,color:#fff

Demo: Managing Assets Using Lansweeper

This walkthrough demonstrates Lansweeper, an asset management solution that discovers infrastructure, hardware, and software assets and helps identify related vulnerabilities.

sequenceDiagram
    participant Engineer as Security Engineer
    participant Lansweeper
    participant Network

    Engineer->>Lansweeper: Install and log in
    Lansweeper->>Network: Scan for servers, devices, hosts
    Network-->>Lansweeper: Return discovered assets
    Lansweeper-->>Engineer: Display Dashboard (asset count & types)
    Engineer->>Lansweeper: Navigate to All Assets
    Lansweeper-->>Engineer: Show detailed asset breakdown (type, IP, MAC, domain)
    Engineer->>Lansweeper: Add missing/segmented asset manually
    Engineer->>Lansweeper: Navigate to Software
    Lansweeper-->>Engineer: List discovered software (name, publisher, version)
    Engineer->>Lansweeper: Navigate to Risk Insights
    Lansweeper-->>Engineer: Show CVEs ranked by risk score, attack vector, attack complexity
    Engineer->>Engineer: Prioritize and patch high/critical vulnerabilities

This single platform provides both hardware/infrastructure asset discovery and software asset discovery, giving the security engineer the visibility needed to understand what’s on the network and where the highest-risk vulnerabilities exist.

Module 2 Recap

• Asset management provides visibility (what assets exist, how many, where located), enables risk analysis and vulnerability management, supports cost control (identifying underutilized assets for disposal), and is essential for meeting compliance obligations (health, privacy, and industry standards).
• The three asset types are infrastructure/hardware, software, and data — each identified and managed using different tools (network discovery platforms like Lansweeper/SolarWinds N-Central for hardware, license management tools like Microsoft Volume Activation Management Tool for software, and classification/DLP tools like Microsoft Purview for sensitive data).
• Two approaches to asset management are the black-box approach (limited visibility, simpler, but leaves uncertainty) and the white-box approach (extensive visibility, more complex, but enables identifying concerns).
• Asset environments — on-premises, cloud, hybrid, and IoT — each carry distinct visibility, control, and tooling implications. Globomantics’ newly acquired assets exist in a hybrid environment.
• The Lansweeper demo illustrated end-to-end asset discovery, inventory, grouping, manual asset registration, software discovery, and CVE-based risk prioritization.

Module 3: Creating a Security Engineering Execution Plan

Defining Processes and Procedures

With asset evaluation, identification, and risk management understood, the next step is to translate that information into action via an execution plan. The foundation of that plan is a clear definition of processes and procedures.

flowchart TD
    P["Processes<br/>High-level<br/>A series of inputs (steps/tasks/activities)<br/>that produce a desired output"]
    Pr["Procedures<br/>Low-level<br/>Step-by-step instructions that define<br/>HOW tasks are performed"]

    Pr -->|Feed into| P
    P -->|Provides| S["Strategic direction for the<br/>security engineer's role and the<br/>organization's overall security efforts"]

    style P fill:#4a6fa5,color:#fff
    style Pr fill:#5b8c5a,color:#fff

An example of a procedure is a set of step-by-step instructions on how to update an Apache system, or detailed instructions on how to configure/modify firewall rules on a web application firewall. Having such detailed procedures keeps security engineers consistent, lowering the risk of misconfigurations that could lead to a cybersecurity incident. These low-level procedures ultimately feed into a higher-level process — for example, “strengthening the web applications of all Globomantics’ newly acquired firms” — which should be included in the overall execution plan because it supports the organization’s overall security.

Strategy for an Execution Plan

With processes and procedures serving as the actions of the plan, the next step is to plan the strategy for execution.

flowchart TD
    Scope["1. Define Scope<br/>(e.g., focus only on newly acquired firms)"]
    Req["2. Gather Requirements<br/>(licenses, upskilling, budget)"]
    Resp["3. Assign Responsibilities<br/>(manageable workload per team member)"]
    DL["4. Define Deadlines<br/>(strict for must-haves, looser for nice-to-haves)"]
    Val["5. Check & Validate<br/>(requirements met, responsibilities upheld)"]

    Scope --> Req --> Resp --> DL --> Val

    style Scope fill:#4a6fa5,color:#fff
    style Val fill:#5b8c5a,color:#fff

Anticipating Roadblocks

mindmap
  root((Execution Plan<br/>Roadblocks))
    Organizational culture
      Resistant to change
      Prefers traditional tooling
    Lack of leadership support
      Difficulty securing resources
    Financial budget
      Often tied to scope being too wide
    Technical infrastructure
      Not in place or too slow to implement
    Skill gaps
      May require additional staffing/expertise

Anticipating these roadblocks in advance allows the team to plan accordingly rather than being caught off guard.

Meeting with Leadership

Once a strategy is defined and roadblocks are anticipated, the next step is presenting the execution plan to leadership to garner support and increase the likelihood of successful implementation.

flowchart TD
    Purpose["1. State the Purpose<br/>Clear, non-technical explanation of how assets will be secured"]
    Scope2["2. Describe the Scope<br/>Business units impacted, team members involved, resources required"]
    Benefits["3. Explain the Benefits<br/>Prioritize financial benefits (cost savings, productivity)"]
    Align["4. Show Alignment<br/>Connect the plan to organizational goals and mission"]
    QA["5. Leave Time for Questions<br/>Come prepared with your own questions too"]
    Proof["6. Provide Proof & References<br/>Evidence the plan can and will succeed"]

    Purpose --> Scope2 --> Benefits --> Align --> QA --> Proof

    style Purpose fill:#4a6fa5,color:#fff
    style Proof fill:#5b8c5a,color:#fff

Case Study: Presenting Globomantics’ Execution Plan

Incorporating Feedback

After the presentation, elicit feedback to:

• Further analyze the plan for deficiencies or areas of concern.
• Understand which parts of the plan are most meaningful from leadership’s perspective.
• Gauge leadership’s overall sentiment toward the plan.

Once feedback is collected, incorporate it by addressing concerns and prioritizing leadership’s interests — ensuring there is clear alignment between the feedback and the plan’s intended outcome. Failing to do so signals that you do not value the input or time of the person providing feedback, which can erode support for the plan.

Module 3 Recap

• Processes are high-level and define what/why; procedures are low-level, step-by-step instructions that define how — procedures feed into processes.
• An execution plan strategy should define scope, gather requirements, assign responsibilities, set deadlines (strict for must-haves, looser for nice-to-haves), and check/validate progress.
• Anticipate roadblocks from organizational culture, lack of leadership support, financial budget, technical infrastructure gaps, and skill gaps.
• When meeting with leadership, clearly state the purpose and scope, articulate benefits (prioritizing financial ones), show alignment with organizational goals/mission, leave room for questions, and provide proof of success.
• After presenting, elicit and incorporate feedback to further bolster leadership support.

Module 4: Continuing and Next Steps

Communication and Reporting

Communication in a plan or project involving multiple team members should never be siloed — updates, responsibilities, and progress must be actively communicated. It’s equally important to tailor communication to the audience:

• Leadership — keep communication at a high level, prioritizing how the execution plan affects (or is currently affecting) business units. Leadership is preoccupied with organizational decision-making, so detailed technical information should be reserved for key stakeholders and technical team members.
• Key stakeholders and technical team members — more detailed, task-oriented information.

Communication is typically formalized through reports — emails, documents, and spreadsheets — presented at interval meetings depending on the organization. Reports should include:

• How feedback from stakeholders and leadership is being incorporated.
• Tracking information related to resource procurement and meeting the requirements defined in the execution strategy.

Reports begin before the execution plan commences and continue throughout its life on a biweekly or monthly cadence, depending on the organization.

Globomantics’ Communication Cadence

sequenceDiagram
    participant SecEng as Security Engineers (Technical)
    participant Stake as Key Stakeholders
    participant Lead as Leadership

    loop Weekly
        SecEng->>SecEng: Weekly team sync
    end
    loop Every 2 weeks
        SecEng->>Stake: Biweekly sync with stakeholders
    end
    Note over SecEng,Stake: After every 2 biweekly syncs
    Stake->>Lead: Monthly meeting (formal, high-level report)
    SecEng-->>Lead: One representative engineer attends to answer technical questions

During the monthly leadership meeting, stakeholders present a formal, high-level document outlining the plan’s progress and its impact on the organization’s business units, while the accompanying security engineer supports them by answering any technical questions leadership may raise.

Execution and Next Steps

Once the Globomantics security engineers have received leadership’s approval — gained by incorporating feedback and communicating that integration back to leadership — the plan can move into execution.

flowchart TD
    Approval["Leadership Approval Received"] --> Purchase["Purchase Resources<br/>(licenses, technology, purchase orders, sales contracts)"]
    Purchase --> Positions["Team Takes Their Positions"]
    Positions --> Commence["Commence Execution Plan<br/>(secure newly acquired IT assets)"]
    Commence --> Monitor["Actively Monitor"]
    Monitor --> Resource["Resource Utilization<br/>(cloud metered-service spend, unused running services)"]
    Monitor --> Levels["Resource Levels<br/>(avoid running out near plan end)"]
    Monitor --> Controls["Control Effectiveness<br/>(validate implemented security controls)"]
    Monitor --> Road["Roadblocks<br/>(delivery delays, deployment issues)"]
    Resource --> Improve["Continuously Improve the Plan"]
    Levels --> Improve
    Controls --> Improve
    Road --> Improve
    Improve -->|Communicate via reports| Monitor

    style Approval fill:#4a6fa5,color:#fff
    style Improve fill:#5b8c5a,color:#fff

Proper monitoring allows the team to continuously improve the plan by addressing identified issues and adapting to evolving security requirements — whether that means fine-tuning configurations for efficiency, addressing small issues before they escalate, or identifying further areas of security concern and risk to address and improve the security of the newly acquired IT assets.

Module 4 Recap

• Know your audience: keep communication high-level for leadership and technically detailed for security engineers and key stakeholders.
• Establish a clear reporting cadence — for Globomantics, a weekly technical sync, a biweekly stakeholder sync, and a monthly leadership meeting (with one representative engineer present to field technical questions).
• Execution can only commence once leadership approval is secured and resources are purchased.
• Once underway, continuously monitor resource utilization (especially cloud metered services), resource levels, control effectiveness, and roadblocks.
• Use monitoring insights to continuously improve the plan and adapt to evolving security requirements.

Summary

This course walked through the full lifecycle of a security engineer’s role in securing a newly acquired IT estate — from understanding the job itself, through inventorying and evaluating assets, to building and executing a formal plan.

flowchart LR
    M1["Module 1<br/>Understand the Security<br/>Engineer Landscape"] --> M2["Module 2<br/>Inventory & Evaluate<br/>IT Assets"]
    M2 --> M3["Module 3<br/>Build the<br/>Execution Plan"]
    M3 --> M4["Module 4<br/>Execute, Monitor,<br/>and Improve"]

    style M1 fill:#4a6fa5,color:#fff
    style M2 fill:#5b8c5a,color:#fff
    style M3 fill:#c96f3c,color:#fff
    style M4 fill:#8c5ab8,color:#fff

Key Principles

• The security engineer role is one tier below the security architect and one tier above the security analyst, tasked with designing, implementing, and maintaining security controls across specializations such as IAM, network, SIEM, physical, application, cloud, and AI security.
• Attack surface visibility is foundational — you cannot defend against what you cannot see.
• Secure design, prevention, and detection are the pillars that support the CIA triad and the NIST incident response lifecycle.
• Objectives feed goals, and goals feed the mission — security engineering work should always be traceable back to a business objective.
• Quantitative risk analysis (ALE = AV × EF × ARO) grounds control selection in measurable, financial terms, and controls should never cost more than the asset they protect.
• Asset inventory across infrastructure/hardware, software, and data — combined with a clear-eyed choice between black-box and white-box visibility — is the prerequisite for any meaningful risk assessment or execution plan.
• Execution plans succeed when scope is tightly defined, requirements and responsibilities are realistic, deadlines distinguish must-haves from nice-to-haves, roadblocks are anticipated, leadership buy-in is earned through a clear and benefit-focused presentation, and feedback is genuinely incorporated.
• Communication must be audience-aware, and execution must be actively monitored and continuously improved even after leadership approval is secured.

Quick-Reference Table

Security Engineering Execution Checklist

• Identify the security engineering specialization(s) relevant to the task at hand.
• Map the initiative back to a specific business objective, goal, and mission.
• Perform (or update) asset inventory across infrastructure/hardware, software, and data.
• Determine whether a black-box or white-box asset management approach is realistic given available information.
• Calculate asset value (AV), exposure factor (EF), SLE, ARO, and ALE where possible to prioritize risk.
• Confirm that proposed security controls cost less than the value of the asset they protect.
• Define processes (the what/why) and procedures (the how) for every planned activity.
• Scope the execution plan narrowly enough to produce a realistic requirements list.
• Assign manageable responsibilities, including staff familiar with newly acquired environments.
• Set strict deadlines for must-haves and looser deadlines for nice-to-haves.
• Anticipate roadblocks: organizational culture, leadership support, budget, technical infrastructure, and skill gaps.
• Prepare a leadership presentation covering purpose, scope, benefits, alignment, Q&A, and proof of success.
• Elicit and incorporate feedback from leadership and stakeholders.
• Establish an audience-appropriate communication and reporting cadence.
• Purchase resources and take positions only after leadership approval.
• Monitor resource utilization, resource levels, control effectiveness, and roadblocks throughout execution.
• Continuously improve the plan based on monitoring insights and evolving security requirements.

Search Terms

security · engineering · asset · evaluation · execution · plan · cybersecurity · fundamentals · networking · systems · assets · management · engineer · globomantics · aligning · case · challenges · communication · identifying · objectives · pillars · risk · study