Index
Assessment Guide
Methodology & Assessment Terms
VAPT (Vulnerability & Penetration Testing)
IAM (Identity & Access Management)
DRP (Disaster Recovery Planning)
HA & HAH (Automation & Healthcare)
Assessment Guide
This part serves as gfxtm’s Assessment Spreadsheet walkthrough.
It explains how to enter data, how the sheets are structured, and how results are interpreted.
For our testing logic, and the transparency of our results;
see our gfxtm’s Methodology & Assessment Terms.
Before a full assessment begins, I provide a Readiness Checklist to ensure your team is prepared. You can View the Checklist Template here to see the baseline requirements for a secure HIT environment.
This guide explains how to correctly enter data, understand sheet structure, and prepare your environment before submitting the assessment.
I. Infrastructure Inventory (User Input)
VAPT-DRP Sheet Architecture
Client Responsibility : Columns A through M are designated for the user to populate with asset data.
Engineer Analysis: Columns N through AW are reserved for the assessor’s technical findings and risk scoring.
HA (Home Assistant) Sheet Architecture
Client Responsibility: Columns A through L for user input.
Engineer Analysis: Columns M through U for assessment results.
Systematic Data Entry
Visual Legend: Columns are color-coded by service type: Red (VAPT), Green (DRP), and Blue (Home Assistant).
Validation Logic: Automated calculations are omitted by design to prevent misleading metrics. Every entry undergoes at least five manual validation checks (data cleanup, correction, and log verification) before a final score is determined. All scoring is manual by design to avoid misleading metrics and ensure human‑verified accuracy.
Guidance: Refer to the footer of each field for boundary definitions and expected value formats.
Note: Before filling out the spreadsheet, you must identify all active assets in your environment.
Tools: If you do not have an up-to-date asset list, use the IP scanners and OS verification commands found on our Resources & Tools page.
Required Data: You will need the IP Address, MAC Address, and exact OS Build (e.g., Windows 10 Pro 22H2) for every device.
II. Data Input Standards
Before you begin:
Ensure you have administrative access to all devices.
Gather network diagrams or IP lists if available.
Confirm consent for VAPT and password testing.
Prepare to provide accurate OS, version, and hardware details.
Use the following schema to ensure data quality. For specific field boundaries, refer to the “expected value” notes in the footer of the spreadsheet cells.
| Column Name | Data Expected | Technical Note |
|---|---|---|
| Machine Name | Hostname / Local DNS name | Primary unique identifier. |
| Machine Type | Workstation, Router, Server, IoT | Define primary duty; list all if multi-role. |
| ID | Asset Tag / Barcode / QR | Physical hardware identifier. |
| IP Addr | IPv4 and/or IPv6 Address | List all active interfaces and virtual IPs. |
| Network Profile | Network Metadata | DNS, Gateway, Subnet, DHCP/Static status. |
| Hardware ID | MAC / UUID / EUI-64 | Unique hardware identifier for all interfaces. |
| Protocols (HA) | Bluetooth, Zigbee, BLE, etc. | Communication standards for IoT devices. |
| Org | Domain / Identity Context | Active Directory, Workgroup, or Domain. |
| OS / Version | OS Type & Build Detail | Distro (Linux), Build # (Win/Mac), or Firmware. |
| Services | Critical Software Stack | List services/builds affecting backup or security. |
| Port Scan Test | Boolean (Yes/No) | Explicit consent for aggressive port scanning. |
| Password Test | Boolean (Yes/No) | Explicit consent for password abuse/brute-force testing. |
| Last Backup Date | YYYY-MM-DD | Required for DRP validation and RPO analysis. |
The “Hardware Baseline” is the foundation of the audit. Accurate data here ensures the security scope is correctly defined.
Machine Name & ID
- Definition: The unique network hostname or internal system identification.
- Requirement: Please identify the Brand/Model (e.g., Dell PowerEdge, Raspberry Pi) or core specs (CPU/RAM/Storage) for custom builds.
Network Profile
- Definition: The logical configuration of the asset’s connection.
- Scope: Includes IP assignment (Static/DHCP), DNS, Gateway, Subnet, and interface type (Fiber/Ethernet/Wi-Fi).
Protocols & Hardware Identifiers
- Standard IT: Uses MAC Address for Ethernet/Wi-Fi.
- Home Automation (HA): Uses EUI-64 (Zigbee), UUID (Matter), or BD_ADDR (Bluetooth).
- Logic: We track the physical “fingerprint” of the radio chip to ensure security persists even if the network assigns a new IP.
III. Submission Protocol
Once the inventory is complete, please notify gfxtm via your established secure communication channel Signal, or Telegram. Do not send unencrypted spreadsheets containing IP architecture via standard email.
Methodology & Assessment Terms
This part serves as gfxtm’s framework. It defines the technical terms used in our gfxtm’s Assessment Spreadsheet, our testing logic, and the transparency of our results.
And gfxtm’s Assessment Guide explains how to enter data, how the sheets are structured, and how results are interpreted.
Expert Analysis
VAPT (Vulnerability & Penetration Testing)
Expert analysis of the “Attack Surface” using a multi-round probing methodology.
Port Scanner & Patch Audit
- Process: A minimum of 2 rounds of testing or more.
- Logic: We identify open logical ports and cross-reference OS versions against known vendor security advisories (CVEs).
- Purpose: To close unnecessary entry points and ensure critical security patches are active.
CVSS Score (Severity Rating)
The Common Vulnerability Scoring System (CVSS) is the global industry standard for assessing risk.
- None (0.0): No security impact.
- Low (0.1 – 3.9): Minor risk; usually requires local physical access.
- Medium (4.0 – 6.9): Significant risk; patching required in the next maintenance cycle.
- High (7.0 – 8.9): Serious threat; exploit is likely possible with remote tools.
- Critical (9.0 – 10.0): Immediate threat; high probability of remote compromise or data loss.
AI-Assisted Analysis & Expert Verification
gfxtm combines automated security assessment tools with AI-assisted analysis and professional expertise.
Rather than relying solely on raw scanner output, our methodology uses AI to help correlate vulnerability information, identify duplicate findings, assess potential false positives, and prioritize security risks.
How We Apply AI
- Finding Correlation: Connect scan results with known CVEs, software versions, and available configuration evidence.
- Intelligent Classification: Help distinguish potential security weaknesses from findings that require further investigation.
- Risk Prioritization: Evaluate findings using technical severity and available infrastructure context.
- Report Assistance: Organize technical findings and support the preparation of remediation recommendations.
Expert Verification
AI assists the assessment process, but it does not replace professional judgment.
A security expert reviews the supporting evidence, validates important findings, evaluates their business impact, and approves the final assessment report.
This hybrid approach aims to reduce repetitive analysis while maintaining the reliability and accountability of professional security assessments.
IAM (Identity & Access Management)
Auditing who can enter your systems and what they are permitted to do once inside.
Principal Identity & Auth Method
- Identity: The unique username, email, or service account name.
- Method: The mechanism used for entry: Password-only, Token, 2FA, or Biometrics (FaceID/Fingerprint).
MFA Bypass & Access Abuse
- MFA Bypass: A technical attempt to force or trick the system into skipping the Second Factor (2FA/MFA) during login.
- Brute Force: Testing the system’s “Counter-Measures” (e.g., account lockouts) after multiple failed login attempts.
Privilege Escalation (Low-to-High)
- Audit Logic: We test if a standard user (“Low Level Admin”) can increase their own permissions to “Upper Admin” via system flaws or misconfigurations.
Random Access (Service‑Dependent Memory Access Test)
- Definition: Attempts to access memory or protected system areas through exposed services or misconfigured daemons.
- Audit Logic: This test is only applicable when the system exposes interfaces that allow indirect memory interaction.
- Purpose: To identify unintended access paths that bypass normal authentication flows.
DRP (Disaster Recovery Planning)
Ensuring “Business Continuity” by following the industry-standard 3-2-1 Backup Rule.
The 3-2-1 Backup Rule
The conventional 3-2-1 rule means:
- Keep three copies of the data, including the production copy.
- Use two types of storage media.
- Keep one copy off-site.
The spreadsheet’s first, second, and remote backup fields help record the backup arrangement, but filling in all three fields does not automatically prove that the 3-2-1 rule is met. The actual copies, storage types, off-site location, and scope of protected data must be assessed.
Recovery Testing
Record the most recent backup date and recovery-test result. A backup that has not been restored in a test has not yet been verified as recoverable. Use the supporting record to document the test performed, its result, and any relevant limitations.
HA & HAH (Automation & Healthcare)
Auditing the reliability, interference, and privacy of “Smart” and “Medical” environments.
Signal Integrity (LQI / RSSI)
- Definition: Measurement of radio strength (Link Quality) for wireless sensors.
- Criticality: Essential for Healthcare (HAH) to ensure “Fall Detection” or “Heart Monitors” remain connected.
Safety Logic
- Definition: The “If-This-Then-That” behavioral rules of the home.
- Transparency: Defines exactly what triggers an alarm if a security boundary is crossed.
Telemetry Audit (Egress)
- Definition: Analysis of “What is sent to the internet.”
- Logic: Identifying if a device is leaking private data (telemetry) to external clouds without the user’s consent.
Purpose and Recommendations
For each identified problem, provide a recommendation that helps the decisions on what to do next to improve security or recoverability.
Explain what was observed, why it matters, and why the current component or configuration may need to be changed, repaired, replaced, or upgraded.
Describe the proposed change and, where useful, any practical alternatives.
Indicate which issues should be addressed first and why.
Include an estimated cost or cost range when possible. Note relevant constraints such as budget, compatibility, licensing, downtime, dependencies, and vendor support.
The recommendation should explain why the proposed action is appropriate, without assuming that replacement or an upgrade is always necessary. If cost or feasibility cannot be confirmed from the available information, state that it requires further investigation or a quotation rather than presenting a guess as a confirmed figure.