Update README.md

README.md

@@ -17,353 +17,7 @@ widget:
   - >-
     Ensuring and supporting information protection awareness and training
     programs
-- source_sentence: >-
-    Which of the following databases are required to be maintained by any system
-    participating in an IPSec VPN?
-  sentences:
-  - >-
-    Gatekeeper bypass through code signing exploitation represents a
-    sophisticated attack vector targeting macOS's application verification
-    mechanism. Understanding detection indicators requires examining both
-    technical artifacts and behavioral patterns associated with compromised
-    digital signatures.\n\n**Primary Technical Indicators:**\n\nCode signing
-    certificate anomalies constitute the most direct indicator. Legitimate
-    applications possess valid, unexpired certificates from trusted authorities
-    like Apple or recognized developers. Suspicious indicators include
-    self-signed certificates, expired certificates, certificates issued by
-    unrecognized authorities, or certificates with unusual subject alternative
-    names (SANs). The `codesign` command reveals signature validity, while
-    examining certificate chains through Keychain Access exposes potential
-    anomalies.\n\nBinary modification signatures often manifest as
-    \\\"unsigned\\\" status for previously signed applications. Gatekeeper
-    maintains a whitelist of notarized applications; unsigned binaries
-    attempting execution trigger alerts in system logs located at
-    `/var/log/system.log`. Additionally, applications with altered code signing
-    identifiers (CSIDs) or modified entitlements may indicate
-    tampering.\n\n**Behavioral and System-Level Indicators:**\n\nProcess
-    execution from non-standard locations frequently accompanies successful
-    bypasses. Legitimate Gatekeeper-approved applications typically execute from
-    `/Applications` or user-specific application directories. Execution from
-    temporary directories, Downloads folders, or unusual paths warrants
-    investigation.\n\nNetwork behavior analysis reveals additional indicators.
-    Compromised applications may exhibit unexpected network connections,
-    particularly to suspicious domains or IP addresses not associated with the
-    legitimate application's functionality. DNS queries to newly registered
-    domains (NRDs) or domains with high entropy often indicate
-    command-and-control communications.\n\n**MITRE ATT&CK Framework
-    Alignment:**\n\nThis technique aligns with T1553.002 (Subvert Trust
-    Controls: Code Signing). Adversaries exploit weaknesses in code signing
-    verification processes, potentially through stolen certificates, certificate
-    authority compromise, or exploitation of bypass mechanisms like manual
-    allowlisting.\n\n**Detection and Response Strategies:**\n\nImplement
-    comprehensive logging using the Unified Logging system with custom
-    predicates monitoring `com.apple.securityd` events. Deploy endpoint
-    detection solutions capable of real-time code signing validation and
-    behavioral analysis. Regularly audit installed applications against
-    known-good baselines, focusing on unsigned or suspiciously signed
-    executables.\n\nNIST Cybersecurity Framework alignment emphasizes continuous
-    monitoring (DE.CM) and anomaly detection capabilities within the Detect
-    function, ensuring organizations maintain visibility into potential
-    Gatekeeper bypass attempts through robust logging and behavioral analysis
-    mechanisms.
-  - Security Policy Database (SPD) and Security Association Database (SAD)
-  - Virus
-- source_sentence: >-
-    How is a supply chain attack implemented through compromised software
-    development kits (SDKs) and their propagation to thousands of applications?
-  sentences:
-  - >-
-    Detecting security label tampering through extended attributes (xattrs)
-    requires implementing comprehensive monitoring and validation mechanisms
-    aligned with NIST Cybersecurity Framework's Detect function and MITRE
-    ATT&CK's Defense Evasion tactics.\n\n**Xattr Monitoring
-    Techniques:**\n\nImplement real-time file system monitoring using tools like
-    `auditd` or Windows Event Tracing to track xattr modifications. Configure
-    audit rules targeting specific security-critical files and directories,
-    focusing on operations like `SETXATTR`, `GETXATTR`, and `LISTXATTR`. This
-    aligns with NIST CSF DE.CM-1 (continuous monitoring) by establishing
-    baseline behaviors for legitimate xattr usage patterns.\n\n**Integrity
-    Validation Methods:**\n\nDeploy cryptographic hashing of security labels
-    stored in xattrs, creating immutable reference values. Implement periodic
-    verification against these baselines using SHA-256 or stronger algorithms.
-    This corresponds to NIST CSF PR.DS-6 (integrity checking mechanisms) and
-    provides detection capabilities for unauthorized
-    modifications.\n\n**Behavioral Analysis:**\n\nEstablish user and process
-    behavior profiling for xattr operations, identifying anomalous patterns that
-    deviate from established baselines. Monitor for unusual privilege escalation
-    attempts modifying security labels, particularly focusing on MITRE ATT&CK
-    technique T1562.008 (Impair Defenses: Disable or Modify Tools) where
-    adversaries manipulate security mechanisms.\n\n**System
-    Integration:**\n\nLeverage SELinux or AppArmor mandatory access controls to
-    restrict unauthorized xattr modifications. Implement centralized logging
-    aggregation correlating xattr changes with process execution and network
-    activities, enabling correlation analysis for sophisticated tampering
-    attempts.\n\n**Detection Signatures:**\n\nDevelop custom detection rules
-    identifying suspicious xattr patterns, including rapid successive
-    modifications, bulk security label changes across multiple files, or
-    modifications from unexpected processes. Integrate these signatures into
-    SIEM platforms for automated alerting and incident response
-    workflows.\n\nThis multi-layered approach provides comprehensive coverage
-    against sophisticated tampering attempts while maintaining operational
-    efficiency through targeted monitoring strategies.
-  - >-
-    Supply chain attacks occur when an attacker injects malicious code into
-    trusted components in the software supply chain, such as open source
-    libraries or SDKs. These components are then distributed to many developers
-    and organizations worldwide. Once they integrate these seemingly legitimate
-    tools into their own products, the malware is automatically embedded within
-    them, propagating widely across various applications and devices. Attackers
-    can also compromise update servers that deliver patches to millions of
-    systems simultaneously. The Sunburst attack on SolarWinds was one such
-    supply chain attack where a malicious update was pushed through the Orion
-    update server. In this case, attackers used the compromised SDK from Pulse
-    Secure to propagate the malware. Because Pulse Secure is used by many
-    organizations for secure remote access solutions, their software development
-    kit was distributed as part of legitimate downloads. Attackers then inserted
-    their own malicious code into that SDK, which in turn infected all products
-    built using it. This attack caused massive damage and forced a significant
-    number of companies to implement new policies regarding software updates and
-    vendor trustworthiness. The SolarWinds supply chain attack also demonstrated
-    the importance of monitoring for suspicious network traffic patterns and
-    adopting multi-factor authentication (MFA) to limit access to sensitive
-    systems. Attackers can easily bypass traditional security measures if they
-    manage to compromise a legitimate update server or SDK provider. Thus, it is
-    essential for companies to carefully vet their third-party software
-    providers and implement strict controls around the development lifecycle of
-    critical applications. Furthermore, adopting robust patch management
-    strategies and keeping an eye on suspicious activity in software
-    repositories are important steps toward reducing the risk of supply chain
-    attacks. Finally, implementing continuous monitoring tools like SIEM can
-    provide early warning signs if any unexpected changes occur within a
-    software component or its corresponding repository. Overall, understanding
-    how supply chain attacks work is crucial for building more secure systems
-    and ensuring that organizations do not inadvertently become victims of such
-    sophisticated breaches in the future. Attackers can easily bypass
-    traditional security measures if they manage to compromise a legitimate
-    update server or SDK provider. Thus, it is essential for companies to
-    carefully vet their third-party software providers and implement strict
-    controls around the development lifecycle of critical applications.
-    Furthermore, adopting robust patch management strategies and keeping an eye
-    on suspicious activity in software repositories are important steps toward
-    reducing the risk of supply chain attacks. Finally, implementing continuous
-    monitoring tools like SIEM can provide early warning signs if any unexpected
-    changes occur within a software component or its corresponding repository.
-  - >-
-    An automated response system for isolating compromised systems requires a
-    multi-layered architecture integrating detection capabilities with
-    orchestrated containment actions, aligned with NIST Cybersecurity
-    Framework's Respond (RS) function and MITRE ATT&CK defensive
-    strategies.\n\n**Core Architecture Components:**\n\nThe system should
-    implement Security Orchestration, Automation, and Response (SOAR) platforms
-    integrated with Security Information and Event Management (SIEM) systems.
-    Central components include: detection engines processing indicators of
-    compromise (IoCs), automated decision matrices for risk assessment, and
-    isolation mechanisms that can quarantine affected assets without disrupting
-    critical operations.\n\n**Detection Integration:**\n\nLeverage MITRE ATT&CK
-    techniques to establish comprehensive monitoring across the attack
-    lifecycle. Implement behavioral analytics detecting tactics like Initial
-    Access (T1566 Phishing), Execution (T1059 Command and Scripting
-    Interpreter), and Defense Evasion (T1027 Obfuscated Files). Deploy endpoint
-    detection and response (EDR) solutions monitoring process execution, network
-    communications, and file system modifications. Integrate threat intelligence
-    feeds correlating observed indicators with known exploitation
-    campaigns.\n\n**Automated Response Logic:**\n\nDesign tiered response
-    capabilities based on confidence levels and asset criticality. Implement
-    network microsegmentation enabling granular isolation through
-    software-defined networking (SDN) controllers. Automated actions should
-    include: DNS sinkholing for malicious domains, firewall rule deployment
-    blocking suspicious traffic patterns, and network switch port isolation.
-    Critical systems require graceful degradation procedures maintaining
-    business continuity.\n\n**Decision Framework:**\n\nEstablish risk scoring
-    algorithms incorporating asset value, threat severity, and exploitation
-    likelihood. Implement approval workflows for high-confidence isolations
-    while enabling rapid containment for confirmed compromises. Integration with
-    Configuration Management Databases (CMDB) ensures accurate asset inventory
-    and dependency mapping before executing isolation
-    procedures.\n\n**Validation and Recovery:**\n\nPost-isolation processes
-    should include automated forensic data collection, incident classification
-    against MITRE ATT&CK framework, and coordinated recovery procedures.
-    Implement continuous monitoring ensuring isolation effectiveness while
-    maintaining operational readiness for subsequent threats.
-- source_sentence: >-
-    What are the best practices for SOC teams to enhance their threat hunting
-    capabilities against ScreenConnect vulnerabilities?
-  sentences:
-  - >-
-    The hiberfil.sys file represents a critical artifact in digital forensics
-    for establishing temporal context and system state at specific points in
-    time. This Windows hibernation file contains compressed memory contents when
-    a system enters power-saving mode, preserving volatile data including
-    running processes, loaded drivers, and network connections.\n\n**Timeline
-    Establishment Through Metadata Analysis**\n\nThe creation timestamp of
-    hiberfil.sys provides definitive evidence of the last hibernation event,
-    establishing a concrete temporal anchor point. This timestamp corresponds to
-    the exact moment Windows initiated hibernation mode, typically occurring
-    during system shutdown or power management events. By analyzing this
-    metadata alongside related artifacts like registry entries
-    (HKLM\\\\SYSTEM\\\\CurrentControlSet\\\\Control\\\\Power) and Event Viewer
-    logs (Event ID 4634 for logoff), investigators can reconstruct precise
-    chronological sequences.\n\n**MITRE ATT&CK Framework Integration**\n\nWithin
-    the MITRE ATT&CK framework, hiberfil.sys analysis supports detection of
-    several techniques including T1055 (Process Injection) and T1070.004 (File
-    Deletion). Adversaries may attempt to manipulate or delete this file to
-    eliminate forensic evidence, making its presence or absence significant for
-    timeline reconstruction.\n\n**NIST Cybersecurity Framework
-    Alignment**\n\nFollowing NIST CSF guidelines, particularly the Respond (RS)
-    and Recover (RC) functions, hiberfil.sys analysis supports incident response
-    activities. The metadata provides crucial temporal context for understanding
-    attack progression and system compromise duration.\n\n**Technical
-    Implementation Considerations**\n\nForensic investigators should examine
-    multiple timestamp artifacts: creation time, last modification time, and
-    access time. However, the creation timestamp remains most reliable as it
-    reflects the initial hibernation event rather than subsequent file
-    operations that might alter other timestamps through normal system
-    operations or potential tampering attempts.\n\nThe hiberfil.sys file size
-    typically correlates with installed RAM capacity, providing additional
-    contextual information about system configuration at the time of
-    hibernation. This metadata correlation strengthens timeline accuracy by
-    validating system state consistency across multiple forensic artifacts.
-  - >-
-    Organizations can effectively leverage log analysis and Endpoint Detection
-    and Response (EDR) systems to monitor Alternate Data Streams (ADS) through a
-    multi-layered approach that addresses both detection capabilities and
-    operational visibility.\n\n**Log Analysis Implementation:**\nWindows Event
-    Logs provide foundational monitoring through Security, System, and
-    Application logs. Critical events include 4663 (object access), 4688
-    (process creation), and 5140 (file share access). Organizations should
-    configure advanced audit policies for \\\"Audit File System\\\" and
-    \\\"Audit Handle Manipulation\\\" under Local Security Policy. Sysmon
-    configuration becomes essential, particularly Event ID 2 (CreateFile) and
-    Event ID 3 (NetworkConnect), as these capture detailed file system
-    interactions that standard Windows logs might miss.\n\n**EDR System
-    Configuration:**\nModern EDR platforms like CrowdStrike, SentinelOne, or
-    Microsoft Defender for Endpoint offer native ADS detection capabilities.
-    These systems should be configured to monitor:\n- File creation/modification
-    events with stream enumeration\n- Process access to files with multiple data
-    streams\n- Registry modifications associated with ADS-enabled
-    applications\n- Network communications from processes accessing hidden
-    streams\n\n**Critical Directory Monitoring:**\nSystem directories requiring
-    enhanced monitoring include %SystemRoot%, %ProgramFiles%, and user profile
-    directories. Implement baseline integrity monitoring using tools like
-    Microsoft's Attack Surface Reduction (ASR) rules or custom PowerShell
-    scripts that enumerate ADS presence through Get-ItemProperty -Name \\\"*\\\"
-    commands.\n\n**MITRE ATT&CK Alignment:**\nThis approach addresses T1096
-    (NTFS File Attributes), T1547.001 (Registry Run Keys/Startup Folder), and
-    T1564.002 (Impair Defenses: Disable or Modify Tools). Detection rules should
-    correlate ADS creation with suspicious process ancestry, particularly
-    PowerShell execution or living-off-the-land binaries.\n\n**Operational
-    Integration:**\nEstablish automated response workflows that quarantine
-    systems exhibiting ADS anomalies while preserving forensic evidence.
-    Implement centralized logging aggregation using SIEM platforms configured to
-    detect patterns indicating ADS abuse, such as rapid stream creation followed
-    by executable access attempts.\n\nThis comprehensive monitoring strategy
-    ensures organizations maintain visibility into ADS activities while
-    minimizing false positives through contextual analysis and behavioral
-    correlation.
-  - >-
-    SOC teams can enhance their threat hunting capabilities against
-    ScreenConnect vulnerabilities by adopting a proactive and iterative approach
-    to searching for indicators of compromise (IoCs) and anomalous activities
-    that may indicate exploitation. Develop and regularly update threat hunting
-    hypotheses based on the latest threat intelligence, focusing on known TTPs
-    associated with the exploitation of ScreenConnect vulnerabilities. Utilize
-    advanced analytics and machine learning tools to sift through large volumes
-    of data for patterns and anomalies that may signify malicious activity.
-    Leverage endpoint detection and response (EDR) tools to continuously monitor
-    endpoints for signs of exploitation, such as unusual PowerShell command
-    execution, modification of system files, or unexpected network connections.
-    Conduct regular vulnerability scans and penetration tests to identify and
-    remediate potential weaknesses in ScreenConnect and other critical systems
-    before attackers can exploit them. Foster collaboration and information
-    sharing with other organizations and cybersecurity communities to gain
-    insights into emerging threats and effective detection and response
-    strategies. Invest in continuous training and development for SOC team
-    members to keep them abreast of the latest cybersecurity trends, tools, and
-    techniques. By implementing these best practices, SOC teams can
-    significantly improve their ability to detect and respond to threats
-    targeting ScreenConnect vulnerabilities, thereby enhancing the overall
-    security posture of their organization.
-- source_sentence: >-
-    How would you use Amcache analysis to detect fileless malware that drops
-    temporary components for initial system compromise?
-  sentences:
-  - >-
-    # Automated Extraction of Empire Agent Configurations: Defensive
-    Analysis\n\n## NIST Cybersecurity Framework Context\n\nWithin the NIST CSF's
-    **Detect (DE)** and **Respond (RS)** functions, organizations must implement
-    capabilities to identify and analyze malicious configurations. PowerShell
-    Empire represents a sophisticated post-exploitation framework mapped to
-    MITRE ATT&CK techniques including T1059.001 (PowerShell) and T1027
-    (Obfuscated Files or Information).\n\n## Detection and Analysis
-    Methodology\n\n**Memory Forensics Approach:**\nDevelop automated tools
-    leveraging memory acquisition frameworks like Volatility or Rekall to
-    identify Empire's in-memory artifacts. Focus on detecting:\n- PowerShell
-    reflection objects characteristic of Empire's module loading\n-
-    Base64-encoded configuration blobs within process memory spaces\n- Registry
-    keys containing encoded agent parameters (typically
-    HKLM\\\\SOFTWARE\\\\Classes\\\\ms-settings)\n\n**File System
-    Analysis:**\nImplement scanning mechanisms targeting:\n- Temporary
-    directories where Empire extracts configurations\n- PowerShell execution
-    logs revealing obfuscated command patterns\n- Event log analysis for
-    suspicious PowerShell execution contexts\n\n## Technical Implementation
-    Framework\n\n**Automated Extraction Pipeline:**\n1. **Signature-Based
-    Detection:** Develop YARA rules identifying Empire's distinctive code
-    patterns and configuration structures\n2. **Memory Parsing:** Implement
-    plugins parsing .NET objects and PowerShell runspaces\n3. **Decryption
-    Routines:** Create automated decoding mechanisms for Empire's XOR-based
-    configuration encryption\n4. **Artifact Correlation:** Cross-reference
-    multiple data sources to validate findings\n\n**MITRE ATT&CK Mapping:**\n-
-    T1083 (File and Directory Discovery)\n- T1057 (Process Discovery)\n- T1005
-    (Data from Local System)\n\n## Defensive Considerations\n\nTools must
-    incorporate anti-evasion techniques, including detection of common
-    obfuscation methods like string concatenation and variable substitution.
-    Integration with SIEM platforms enables real-time alerting when Empire
-    artifacts are discovered.\n\n**Validation Framework:**\nImplement
-    multi-layered validation ensuring extracted configurations correspond to
-    active threats rather than benign PowerShell activity. This includes
-    behavioral analysis correlating configuration parameters with observed
-    network communications and file system modifications
-  - To capture and display network traffic
-  - >-
-    Amcache analysis provides critical forensic artifacts for detecting fileless
-    malware employing temporary component deployment during initial system
-    compromise, aligning with MITRE ATT&CK techniques T1055 (Process Injection)
-    and T1620 (Reflective Code Loading).\n\n**Amcache Artifact Analysis
-    Framework:**\n\nThe Amcache.hve registry hive maintains comprehensive
-    application execution metadata, including file paths, hashes, and execution
-    timestamps. For fileless malware detection, focus on:\n\n1. **Temporary File
-    Creation Patterns**: Analyze entries with suspicious temporal clustering in
-    the \\\"Programs\\\" key, particularly executables stored in system
-    directories (C:\\\\Windows\\\\Temp,
-    C:\\\\Users\\\\[User]\\\\AppData\\\\Local\\\\Temp). Legitimate applications
-    typically exhibit predictable installation patterns, while malicious
-    components often manifest as isolated, recently-created executables.\n\n2.
-    **Hash-Based Indicators**: Cross-reference SHA-1 hashes against threat
-    intelligence feeds and known malware signatures. Fileless malware frequently
-    employs legitimate system binaries for process hollowing (T1055.012) or
-    reflective DLL loading (T1620), making hash analysis crucial for identifying
-    repurposed executables.\n\n3. **Execution Chain Analysis**: Examine
-    parent-child relationships within Amcache entries to identify anomalous
-    process spawning patterns. Fileless malware often exhibits unusual execution
-    chains, particularly when temporary components spawn from unexpected parent
-    processes or system services.\n\n**NIST CSF Implementation
-    Strategy:**\n\nUnder the Detect (DE) function, specifically DE.AE-2
-    (Detected events are analyzed), implement continuous Amcache monitoring
-    through:\n\n- **Baseline Establishment**: Create organizational baselines
-    for normal temporary file creation patterns and execution behaviors\n-
-    **Anomaly Detection**: Deploy automated analysis tools to identify
-    deviations from established baselines\n- **Correlation Analysis**: Integrate
-    Amcache findings with network traffic analysis and endpoint detection
-    systems\n\n**Advanced Detection Methodologies:**\n\nUtilize PowerShell-based
-    parsing scripts or specialized forensic tools like KAPE to extract and
-    analyze Amcache artifacts. Focus on:\n\n- Unusual file extensions in
-    temporary directories\n- Executables created immediately before suspicious
-    network activity\n- Components with execution timestamps correlating with
-    initial access events\n- Hash collisions or similarities between temporary
-    files and known malware families\n\nThis approach enables proactive
-    identification of fileless malware campaigns leveraging temporary components
-    for system compromise, supporting comprehensive threat hunting and incident
-    response activities within enterprise environments.
+
 pipeline_tag: sentence-similarity
 library_name: sentence-transformers
 base_model:
@@ -435,41 +89,6 @@ print(similarities)
 #         [ 0.0078, -0.0407,  1.0000]])
 ```
 
-<!--
-### Direct Usage (Transformers)
-
-<details><summary>Click to see the direct usage in Transformers</summary>
-
-</details>
--->
-
-<!--
-### Downstream Usage (Sentence Transformers)
-
-You can finetune this model on your own dataset.
-
-<details><summary>Click to expand</summary>
-
-</details>
--->
-
-<!--
-### Out-of-Scope Use
-
-*List how the model may foreseeably be misused and address what users ought not to do with the model.*
--->
-
-<!--
-## Bias, Risks and Limitations
-
-*What are the known or foreseeable issues stemming from this model? You could also flag here known failure cases or weaknesses of the model.*
--->
-
-<!--
-### Recommendations
-
-*What are recommendations with respect to the foreseeable issues? For example, filtering explicit content.*
--->
 
 ## Training Details
 
@@ -507,155 +126,6 @@ You can finetune this model on your own dataset.
 - `num_train_epochs`: 20
 - `multi_dataset_batch_sampler`: round_robin
 
-#### All Hyperparameters
-<details><summary>Click to expand</summary>
-
-- `overwrite_output_dir`: False
-- `do_predict`: False
-- `eval_strategy`: steps
-- `prediction_loss_only`: True
-- `per_device_train_batch_size`: 32
-- `per_device_eval_batch_size`: 32
-- `per_gpu_train_batch_size`: None
-- `per_gpu_eval_batch_size`: None
-- `gradient_accumulation_steps`: 1
-- `eval_accumulation_steps`: None
-- `torch_empty_cache_steps`: None
-- `learning_rate`: 5e-05
-- `weight_decay`: 0.0
-- `adam_beta1`: 0.9
-- `adam_beta2`: 0.999
-- `adam_epsilon`: 1e-08
-- `max_grad_norm`: 1
-- `num_train_epochs`: 20
-- `max_steps`: -1
-- `lr_scheduler_type`: linear
-- `lr_scheduler_kwargs`: {}
-- `warmup_ratio`: 0.0
-- `warmup_steps`: 0
-- `log_level`: passive
-- `log_level_replica`: warning
-- `log_on_each_node`: True
-- `logging_nan_inf_filter`: True
-- `save_safetensors`: True
-- `save_on_each_node`: False
-- `save_only_model`: False
-- `restore_callback_states_from_checkpoint`: False
-- `no_cuda`: False
-- `use_cpu`: False
-- `use_mps_device`: False
-- `seed`: 42
-- `data_seed`: None
-- `jit_mode_eval`: False
-- `use_ipex`: False
-- `bf16`: False
-- `fp16`: False
-- `fp16_opt_level`: O1
-- `half_precision_backend`: auto
-- `bf16_full_eval`: False
-- `fp16_full_eval`: False
-- `tf32`: None
-- `local_rank`: 0
-- `ddp_backend`: None
-- `tpu_num_cores`: None
-- `tpu_metrics_debug`: False
-- `debug`: []
-- `dataloader_drop_last`: True
-- `dataloader_num_workers`: 0
-- `dataloader_prefetch_factor`: None
-- `past_index`: -1
-- `disable_tqdm`: False
-- `remove_unused_columns`: True
-- `label_names`: None
-- `load_best_model_at_end`: False
-- `ignore_data_skip`: False
-- `fsdp`: []
-- `fsdp_min_num_params`: 0
-- `fsdp_config`: {'min_num_params': 0, 'xla': False, 'xla_fsdp_v2': False, 'xla_fsdp_grad_ckpt': False}
-- `fsdp_transformer_layer_cls_to_wrap`: None
-- `accelerator_config`: {'split_batches': False, 'dispatch_batches': None, 'even_batches': True, 'use_seedable_sampler': True, 'non_blocking': False, 'gradient_accumulation_kwargs': None}
-- `deepspeed`: None
-- `label_smoothing_factor`: 0.0
-- `optim`: adamw_torch
-- `optim_args`: None
-- `adafactor`: False
-- `group_by_length`: False
-- `length_column_name`: length
-- `ddp_find_unused_parameters`: None
-- `ddp_bucket_cap_mb`: None
-- `ddp_broadcast_buffers`: False
-- `dataloader_pin_memory`: True
-- `dataloader_persistent_workers`: False
-- `skip_memory_metrics`: True
-- `use_legacy_prediction_loop`: False
-- `push_to_hub`: False
-- `resume_from_checkpoint`: None
-- `hub_model_id`: None
-- `hub_strategy`: every_save
-- `hub_private_repo`: None
-- `hub_always_push`: False
-- `gradient_checkpointing`: False
-- `gradient_checkpointing_kwargs`: None
-- `include_inputs_for_metrics`: False
-- `include_for_metrics`: []
-- `eval_do_concat_batches`: True
-- `fp16_backend`: auto
-- `push_to_hub_model_id`: None
-- `push_to_hub_organization`: None
-- `mp_parameters`: 
-- `auto_find_batch_size`: False
-- `full_determinism`: False
-- `torchdynamo`: None
-- `ray_scope`: last
-- `ddp_timeout`: 1800
-- `torch_compile`: False
-- `torch_compile_backend`: None
-- `torch_compile_mode`: None
-- `include_tokens_per_second`: False
-- `include_num_input_tokens_seen`: False
-- `neftune_noise_alpha`: None
-- `optim_target_modules`: None
-- `batch_eval_metrics`: False
-- `eval_on_start`: False
-- `use_liger_kernel`: False
-- `eval_use_gather_object`: False
-- `average_tokens_across_devices`: False
-- `prompts`: None
-- `batch_sampler`: batch_sampler
-- `multi_dataset_batch_sampler`: round_robin
-- `router_mapping`: {}
-- `learning_rate_mapping`: {}
-
-</details>
-
-### Training Logs
-| Epoch   | Step | Training Loss |
-|:-------:|:----:|:-------------:|
-| 1.0     | 139  | -             |
-| 2.0     | 278  | -             |
-| 3.0     | 417  | -             |
-| 3.5971  | 500  | 1.1678        |
-| 4.0     | 556  | -             |
-| 5.0     | 695  | -             |
-| 6.0     | 834  | -             |
-| 7.0     | 973  | -             |
-| 7.1942  | 1000 | 0.0258        |
-| 8.0     | 1112 | -             |
-| 9.0     | 1251 | -             |
-| 10.0    | 1390 | -             |
-| 10.7914 | 1500 | 0.0037        |
-| 11.0    | 1529 | -             |
-| 12.0    | 1668 | -             |
-| 13.0    | 1807 | -             |
-| 14.0    | 1946 | -             |
-| 14.3885 | 2000 | 0.0016        |
-| 15.0    | 2085 | -             |
-| 16.0    | 2224 | -             |
-| 17.0    | 2363 | -             |
-| 17.9856 | 2500 | 0.0009        |
-| 18.0    | 2502 | -             |
-| 19.0    | 2641 | -             |
-| 20.0    | 2780 | -             |
 
 
 ### Framework Versions
@@ -669,47 +139,13 @@ You can finetune this model on your own dataset.
 
 ## Citation
 
-### BibTeX
+## Reference
 
-#### Sentence Transformers
-```bibtex
-@inproceedings{reimers-2019-sentence-bert,
-    title = "Sentence-BERT: Sentence Embeddings using Siamese BERT-Networks",
-    author = "Reimers, Nils and Gurevych, Iryna",
-    booktitle = "Proceedings of the 2019 Conference on Empirical Methods in Natural Language Processing",
-    month = "11",
-    year = "2019",
-    publisher = "Association for Computational Linguistics",
-    url = "https://arxiv.org/abs/1908.10084",
-}
 ```
-
-#### MultipleNegativesRankingLoss
-```bibtex
-@misc{henderson2017efficient,
-    title={Efficient Natural Language Response Suggestion for Smart Reply},
-    author={Matthew Henderson and Rami Al-Rfou and Brian Strope and Yun-hsuan Sung and Laszlo Lukacs and Ruiqi Guo and Sanjiv Kumar and Balint Miklos and Ray Kurzweil},
-    year={2017},
-    eprint={1705.00652},
-    archivePrefix={arXiv},
-    primaryClass={cs.CL}
+@article{aghaei2025securebert,
+  title={SecureBERT 2.0: Advanced Language Model for Cybersecurity Intelligence},
+  author={Aghaei, Ehsan and Jain, Sarthak and Arun, Prashanth and Sambamoorthy, Arjun},
+  journal={arXiv preprint arXiv:2510.00240},
+  year={2025}
 }
 ```
-
-<!--
-## Glossary
-
-*Clearly define terms in order to be accessible across audiences.*
--->
-
-<!--
-## Model Card Authors
-
-*Lists the people who create the model card, providing recognition and accountability for the detailed work that goes into its construction.*
--->
-
-<!--
-## Model Card Contact
-
-*Provides a way for people who have updates to the Model Card, suggestions, or questions, to contact the Model Card authors.*
--->