In daily ICT consulting, especially when interfacing corporate infrastructures with law firms or Public Administrations, a known and frustrating technical limitation often arises: the attachment size limit of Certified Electronic Mail (PEC). Most Italian PEC providers impose a hard cap of 50 to 100 MB. But how do you proceed when you need to legally transmit log archives, digital forensic images, or entire CAD projects that exceed several gigabytes?

The optimal solution is to decouple the physical transport of the file from its legal certification. In this article, we will explore how to use Python to automate the upload of a large file to Google Cloud Storage, calculate its SHA-256 hash to guarantee integrity, and automatically send a PEC containing the download link and the cryptographic fingerprint.

Solution Architecture

Including the file's cryptographic hash within the body of a PEC message legally binds that specific file (hosted externally) to the certified communication. If even a single bit of the file on Google Cloud Storage were to change, the hash would no longer match the one "notarized" by the PEC delivery receipt.

• Hash Calculation: We use SHA-256 to generate a unique fingerprint of the local file.
• Cloud Storage: We upload the file to a GCS bucket and generate a Signed URL or public link for downloading.
• SMTP Automation: We send the PEC using Python's standard libraries, authenticating on the PEC provider's SMTP server.

The Python Script: Step-by-Step Implementation

To run this script, ensure you have the official Google Cloud library installed:
pip install google-cloud-storage. You will also need a Service Account JSON with write permissions to your bucket.

import hashlib
import smtplib
from email.message import EmailMessage
from google.cloud import storage
import os

# Variable Configuration
FILE_PATH = "C:\\Projects\\huge_file_to_send.zip"
BUCKET_NAME = "your-corporate-bucket"
PEC_SENDER = "your.email@pec.it"
PEC_PASSWORD = "YourSecurePassword"
PEC_RECIPIENT = "recipient@pec.it"
SMTP_SERVER = "smtps.pec.aruba.it" # Example for Aruba PEC
SMTP_PORT = 465

def calculate_sha256(file_path):
    """Calculates the SHA-256 hash of a local file."""
    sha256_hash = hashlib.sha256()
    with open(file_path, "rb") as f:
        # Read the file in chunks to handle large files efficiently
        for byte_block in iter(lambda: f.read(4096), b""):
            sha256_hash.update(byte_block)
    return sha256_hash.hexdigest()

def upload_to_gcs(file_path, bucket_name):
    """Uploads the file to Google Cloud Storage and returns the URL."""
    # Set the environment variable for GCP authentication
    os.environ["GOOGLE_APPLICATION_CREDENTIALS"] = "service_account.json"
    
    storage_client = storage.Client()
    bucket = storage_client.bucket(bucket_name)
    blob_name = os.path.basename(file_path)
    blob = bucket.blob(blob_name)
    
    print(f"[*] Uploading to GCS: {blob_name}...")
    blob.upload_from_filename(file_path)
    
    # Makes the file temporarily accessible
    # Note: For production use Signed URLs for enhanced security
    blob.make_public()
    return blob.public_url

def send_pec(file_url, file_hash):
    """Sends the link and hash via PEC (Certified Email)."""
    msg = EmailMessage()
    msg['Subject'] = "Project Transmission and Cryptographic Hash"
    msg['From'] = PEC_SENDER
    msg['To'] = PEC_RECIPIENT
    
    message_body = f"""
    Dear User,
    
    The requested project is transmitted via virtual attachment. 
    Due to PEC size limitations, the file is available for download at the following secure link:
    
    DOWNLOAD LINK: {file_url}
    
    To ensure the integrity and legal validity of this transmission, the file's cryptographic footprint is provided:
    ALGORITHM: SHA-256
    HASH: {file_hash}
    
    Best regards,
    The System Administrator
    """
    msg.set_content(message_body)
    
    print("[*] Connecting to PEC SMTP server...")
    with smtplib.SMTP_SSL(SMTP_SERVER, SMTP_PORT) as server:
        server.login(PEC_SENDER, PEC_PASSWORD)
        server.send_message(msg)
    print("[+] PEC sent successfully!")

if __name__ == "__main__":
    print("[*] Starting Hash calculation...")
    file_hash = calculate_sha256(FILE_PATH)
    print(f"[+] SHA-256 Hash: {file_hash}")
    
    file_url = upload_to_gcs(FILE_PATH, BUCKET_NAME)
    print(f"[+] File URL: {file_url}")
    
    send_pec(file_url, file_hash)

Conclusions for IT Risk Management

This hybrid infrastructure not only solves a burdensome operational roadblock, but it does so while complying with strict Information Security standards. By utilizing cloud buckets, we can enforce automated Data Retention policies (e.g., auto-deleting the blob after 30 days), while embedding the hash into the PEC transaction legally seals the perimeter of our corporate communication.

Fourth episode of IT First Aid. If your screen's bottom-right corner is filling up with alarming ad warnings, it's not a virus. It's spam sent via browser notifications. Let's clean it up.

Revoking Notification Permissions (Chrome)

The problem arises from absentmindedly clicking "Allow" on deceptive sites.

• Open Chrome and click the three dots in the top right > Settings.
• Go to Privacy and security > Site Settings > Notifications.
• Scroll down to the "Allowed" section. Remove any suspicious or unknown site.

Deep Scan

If windows pop up on their own, you might have a malicious extension (Adware). Download and run a free scan with Malwarebytes AdwCleaner, a tool specialized in browser issues.

We have reached the final act of our Playbook. We have discovered assets, analyzed threats, and chosen the calculation framework. Now, all this data must converge into a single, vital document: the Risk Register. This is not a mere bureaucratic compliance task; it is the executive dashboard of the entire IT department.

1. The Anatomy of a Risk Register

Whether managed on an advanced Excel spreadsheet or through a dedicated GRC (Governance, Risk, and Compliance) platform, a mature Risk Register must contain specific information:

• Risk Description: What can happen and to which asset.
• Risk Owner: The business owner responsible for this risk (Often this is NOT IT, but the business director the asset belongs to!).
• Inherent Risk: The level of risk without any active defenses.
• Mitigations / Countermeasures: The controls currently in place (e.g., Firewalls, EDR, Immutable Backups).
• Residual Risk: The risk that remains after countermeasures are applied. This is the number that truly matters.

2. The Heat Map Trap

To communicate risk to the Board, "Heat Maps" (Risk matrices with Green, Yellow, and Red squares) are often used. Beware: a Heat Map based solely on gut feelings ("I think the impact is high") is misleading. The matrix colors must reflect the financial calculations (ALE) and the SLAs agreed upon in the Business Impact Assessment (BIA).

3. From Assessment to Governance

The Risk Register is not a document you fill out once a year before the ISO 27001 audit and then forget about. It is a living tool. When the IT Manager sits down with the Board to discuss the annual budget, the Risk Register is the only necessary documentation: "We have 3 risks in the Red zone (Unacceptable risk). To move them into the Yellow or Green zone (Accepted/Mitigated risk), the required investment for technology X is Y".

This is the moment when cybersecurity stops being perceived as an incomprehensible technical cost and becomes strategic business value. The Risk Assessment circle is finally complete.

Index: IT Risk Assessment Playbook

• Ep. 1: Asset Visibility and Shadow IT
• Ep. 2: Threat Modeling: Knowing the Adversary
• Ep. 3: Framework Comparison: NIST vs FAIR
• Ep. 4: The Risk Register: From Theory to Governance [You are here]

We have our assets and we know the threats. Now it's time to connect the dots and calculate the Risk. As an IT Manager, the temptation is to invent a custom spreadsheet, but in the corporate world (and to pass compliance audits), you must rely on recognized standards. Let's explore the two most authoritative frameworks.

1. The Qualitative Approach: NIST SP 800-30

NIST's Special Publication 800-30 is the de facto standard of the US government. It offers a rigorous and tested approach. It relies predominantly on qualitative or semi-quantitative assessments: probability and impact are classified on scales such as Very High, High, Medium, Low.

The Pro: It is relatively simple to implement and provides a solid, unassailable baseline for compliance (e.g., ISO 27001).
The Con: It is subjective. One sysadmin's "High Risk" might be another's "Medium Risk", and most importantly, it doesn't tell the CFO how much money the company is risking.

2. The Quantitative Approach: FAIR

FAIR (Factor Analysis of Information Risk) flips the paradigm. Instead of using colors and adjectives, it uses statistics and financial modeling (like Monte Carlo simulations). It breaks risk down into its fundamental mathematical factors: Event Frequency and Financial Loss Magnitude (very reminiscent of the ARO and ALE concepts we discussed previously).

The Pro: It speaks the Board's language. Instead of saying "There is a critical risk of ransomware", FAIR allows you to say: "There is a 15% probability of experiencing ransomware this year, with an expected loss between €50,000 and €250,000".
The Con: It requires historical data, precise measurements, and a very high level of corporate maturity to be implemented correctly.

3. Which to choose?

The strategic advice is a hybrid approach: use NIST SP 800-30 for the initial screening and to quickly discard minor risks, and apply FAIR's quantitative analysis only to risks considered "High" or "Critical" to justify security investments (ROI) to management.

Index: IT Risk Assessment Playbook

• Ep. 1: Asset Visibility and Shadow IT
• Ep. 2: Threat Modeling: Knowing the Adversary
• Ep. 3: Framework Comparison: NIST vs FAIR [You are here]
• Ep. 4: The Risk Register: From Theory to Governance

In the first episode, we mapped our territory, identifying assets and defusing Shadow IT. Now that we know what we must defend, the next question is: who will attack us, and how will they do it? This logical step is called Threat Modeling.

1. Thinking like an attacker

Threat Modeling is the structured exercise of putting yourself in the adversary's shoes. It is not about making an endless list of irrational fears, but systematically identifying architectural and operational vulnerabilities before they are exploited. It means stopping configuring firewalls based on "gut feelings" and starting to place defenses where the attacker is most likely to strike.

2. Two approaches compared: STRIDE and MITRE ATT&CK

To avoid getting lost in theory, the IT industry uses highly specific frameworks:

• STRIDE (Microsoft): Born in software development but excellent for IT architecture. It divides threats into six categories: Spoofing (pretending to be someone else), Tampering (altering data), Repudiation (untraceability of actions), Information Disclosure (data leaks), Denial of Service (blocking systems), and Elevation of Privilege. It forces you to look at your network and ask: "How can someone spoof an identity here?".
• MITRE ATT&CK: The operational bible for Blue Teams. It is a matrix based on real-world data that maps Tactics (the attacker's goal) and Techniques (how they achieve it). It is perfect for testing your EDR/XDR systems: "If a ransomware uses technique T1003 to steal credentials from RAM, will our SOC notice?".

3. Mapping threats to assets

The result of Threat Modeling must intersect with Asset Discovery. If we discovered an old industrial PLC server (Asset), and we know our sector is targeted by ransomware exploiting unencrypted OT protocols (Threat), we have just identified a critical Risk to include in our Assessment.

Index: IT Risk Assessment Playbook

• Ep. 1: Asset Visibility and Shadow IT
• Ep. 2: Threat Modeling: Knowing the Adversary [You are here]
• Ep. 3: Framework Comparison: NIST vs FAIR
• Ep. 4: The Risk Register: From Theory to Governance

There is a fundamental axiom in cybersecurity that every IT Manager should have engraved on their desk: "You cannot protect what you don't know you have". Any Risk Assessment activity that skips the Discovery phase is doomed to fail, leaving blind spots where risks proliferate unchecked. Welcome to the first chapter of our operational Playbook.

1. The Invisible Enemy: Shadow IT

Shadow IT represents the collection of devices, software, and cloud services used within the company without explicit approval from the IT department. This could be a Wi-Fi access point installed by an employee for "better signal," or an entire database moved to a personal cloud account for convenience. From a risk perspective, Shadow IT is a landmine: it is unpatched, unmonitored, and often exposes critical data to the Internet.

2. Discovery Techniques: Active vs Passive

To map the infrastructure and flush out Shadow IT, we must adopt scanning strategies that do not impact business continuity, especially in Industrial (OT) or Medical environments:

• Active Discovery: Directly querying assets (ping, port scanning). Highly precise but can be "noisy" or crash sensitive legacy devices.
• Passive Discovery: Listening to network traffic via SPAN/Mirror ports. Non-invasive, perfect for identifying assets that "talk" spontaneously, but less effective for silent ones.

3. The Toolset: Open and Commercial Solutions

The choice of tool depends on network scale and the need for automation. Here are the market benchmarks every professional should know:

• Open Source Solutions:
  • Nmap: The "Swiss Army knife." Indispensable for specific discovery and OS fingerprinting, but requires high technical skills to scale.
  • Netdisco: Excellent for mapping network topology via SNMP, allowing you to see exactly which switch port each device is connected to.
• Commercial Solutions:
  • runZero (formerly Rumble): Likely the most innovative tool today. It performs "unauthenticated" (credential-less) and agentless active discovery, identifying IT, OT, and IoT assets with surgical precision without crashing systems.
  • Lansweeper: A complete IT Asset Management solution that combines network and agent-based scanning to maintain an up-to-date CMDB.

4. Conclusion

Without a granular and dynamic asset inventory, the risk calculation (ALE/ARO) discussed in previous posts remains a theoretical exercise based on partial data. Visibility is the prerequisite for security.

Index: IT Risk Assessment Playbook

• Ep. 1: Asset Visibility and Shadow IT [You are here]
• Ep. 2: Threat Modeling: Knowing the Adversary
• Ep. 3: Framework Comparison: NIST vs FAIR
• Ep. 4: The Risk Register: From Theory to Governance

There is a fundamental paradigm that every security professional must accept to transition from technician to manager: zero risk does not exist. We can optimize, patch, and mitigate endlessly, but sooner or later, defenses will be breached. This is the Assume Breach philosophy. And this is where our Risk Management series concludes, talking about resilience.

1. From Mitigation to Survival

When the risk turns into a real incident (a ransomware, a natural disaster, a destructive attack), the financial metrics of the BIA become our survival manual. The clock starts ticking against our RTO (Recovery Time Objective). It's no longer the time to prevent; it's the time to react by executing the Business Continuity Plan (BCP) and the Disaster Recovery Plan (DRP).

2. The Role of DFIR (Digital Forensics and Incident Response)

In the event of an incident, the IT's instinctive reaction is to shut everything down or format to restart quickly. This is a fatal mistake. Doing so destroys evidence (RAM, volatile logs, system artifacts).

The correct approach requires a structured Incident Response procedure (e.g., NIST or SANS frameworks). First, you contain the threat by isolating networks, then perform a quick Digital Forensics analysis to understand "Patient Zero", the extent of the damage, and most importantly, how the attacker got in. If we restore backups without closing the original flaw (Eradication), we will be re-encrypted the very next day.

3. Closing the Loop

True IT risk management is circular. The incident (even if only simulated in a Tabletop Exercise) provides the "Lessons Learned" to update our probability (ARO) and impact (EV) estimates, improving the following year's Business Impact Assessment.

Leading IT does not mean building insurmountable walls, but building ships capable of floating and continuing the course even after taking on water. That is true Resilience.

In the next few posts, we'll explore the other side of IT Risk Management, diving into the details of IT risk assessment and attack surface reduction through mitigation techniques.

Series Index: The Risk Matrix Series

• Ep. 1: The Risk Matrix Series - From BIA to the Mathematics of Risk (EV, ARO, ALE)
• Ep. 2: The Risk Matrix Series - Vulnerability vs. Risk: Why a CVSS 9.8 isn't always a Business Emergency
• Ep. 3: The Risk Matrix Series - Governing Risk: Translating Metrics into ISO 27001 and NIS 2 Compliance
• Ep. 4: The Risk Matrix Series - Third-Party Risk: How to Manage (and Transfer) IT Vendor Risk
• Ep. 5: The Risk Matrix Series - Beyond Mitigation: DFIR, & Business Continuity, and the Art of Surviving [You are here]

The corporate perimeter is dead. Modern companies are interconnected ecosystems: we use SaaS for email, IaaS for servers, and rely on Managed Service Providers (MSP) for helpdesk support. But outsourcing a service does not mean outsourcing responsibility. Welcome to the complex world of Third-Party Risk Management (TPRM).

1. The Cloud Illusion

One of the most dangerous cognitive biases is thinking: "We are on Google Workspace or Microsoft 365, so our data is safe". Reality is dictated by the Shared Responsibility Model. The Cloud provider is responsible for the security of the Cloud (hardware). You remain solely responsible for the security in the Cloud (access, backups, configurations).

2. Risk Transfer: Contracts and SLAs

In the first episode, we talked about Risk Transfer. The IT Supply Chain is the main arena for this strategy. When we integrate a critical vendor, how do we transfer the risk?

• Ironclad SLAs: Strict financial penalties if the vendor fails to meet uptime requirements aligned with our RTO.
• DPA (Data Processing Agreement): Clear contracts on data protection (GDPR).
• Right to Audit: The clause that allows us to verify the vendor's actual security posture.

3. Zero Trust applied to vendors

The largest cyberattacks in recent years originated from the Supply Chain. A compromised vendor is a bridge into your network. 

A few days ago I read an article by Robert Lemos published on Dark Reading regarding various leaks that have occurred in recent weeks, among which the noteworthy leak of Trivy security scanner is certainly worth noting, where attackers exploited a vulnerability in GitHub Actions.

The technical answer is a Zero Trust architecture: vendors must access only via profiled VPNs/ZTNs, with mandatory MFA and granular privileges that are strictly monitored. Trust is good, monitoring is better.

Series Index: The Risk Matrix Series

• Ep. 1: The Risk Matrix Series - From BIA to the Mathematics of Risk (EV, ARO, ALE)
• Ep. 2: The Risk Matrix Series - Vulnerability vs. Risk: Why a CVSS 9.8 isn't always a Business Emergency
• Ep. 3: The Risk Matrix Series - Governing Risk: Translating Metrics into ISO 27001 and NIS 2 Compliance
• Ep. 4: The Risk Matrix Series - Third-Party Risk: How to Manage (and Transfer) IT Vendor Risk [You are here]
• Ep. 5: The Risk Matrix Series - Beyond Mitigation: DFIR & Business Continuity, and the Art of Surviving