SL1 Ibiza 12.3.3 Release Notification
We are pleased to announce that SL1 Ibiza 12.3.3 is now available. The release and documentation can be accessed using the following links: https://support.sciencelogic.com/s/release-file/aBtVL0000000tED0AY/1233 If you are planning to consume SL1 Ibiza 12.3.3, be advised of the following: The 12.3.3 release is available only as a patch; there is no ISO version. You can upgrade to this release directly from the following releases: SL1 12.3.0 through 12.3.2 SL1 12.2.1.1 through 12.2.6 SL1 12.1.2, if all of your SL1 appliances have been converted to OL8 NOTE: If you are on12.1.2, you should upgrade directly to 12.3.3 without consuming the 12.2.x releases. If you are on 12.1.0.2 or 12.1.1, you can upgrade to 12.1.2, convert to OL8, and then upgrade directly to 12.3.3 without consuming the 12.2.x releases. 12.2.x and 12.3.0 STIG-compliant users can upgrade to this release. Users who are on an 11.x MUD system cannot upgrade directly to this release; they must first follow the approved conversion process from 11.x MUD to 12.2.1.1 STIG and then upgrade to 12.3.3 STIG. For more information, see the section on STIG Support in SL1 Ibiza 12.3.3 release notes. AWS deployments that are using Aurora 3 can upgrade to this release. If you are currently deployed using Aurora 2, you can upgrade to this release but you must perform a post-upgrade Aurora 2 to 3 conversion. SL1 12.3.3 is Department of Defense Information Network (DoDIN)-certified. For more information, see the SL1 Ibiza 12.3.3 release notes18Views0likes0CommentsMastering Terminal Security: Why TMUX Matters in Modern Enterprise Environments
In the evolving landscape of enterprise IT, security isn't a feature—it’s a foundation. As organizations grow more distributed and systems become increasingly complex, securing terminal sessions accessed through SSH is a mission-critical component of any corporate security posture. One tool rising in prominence for its role in fortifying SSH access control is tmux, and it's more than just a handy utility—it's a security enabler. As part of ScienceLogic’s harden the foundation initiative, the SL1 platform on the 12.2.1 or later release introduces improved tmux session control capabilities to meet industry leading security standards. ScienceLogic TMUX resources: SL1 Release Notes KB Article: What is TMUX and why is it now default on SL1? KB Article: Unable to Copy or Paste Text in SSH Sessions TMUX Configuration Cheat Sheet Increase ITerm TMUX Window What is TMUX? tmux (short for terminal multiplexer) is a command-line tool that allows users to open and manage multiple terminal sessions from a single SSH connection. Think of it as a window manager for your terminal—enabling users to split screens, scroll through logs, copy/paste content, and manage persistent sessions across disconnects. tmux is now running by default when you SSH into an SL1 system. This isn’t just a user experience enhancement—it’s a strategic security upgrade aligned with best practices in access control and session management. Why TMUX Matters for Security Security teams understand idle or abandoned SSH sessions pose real risks—whether from unauthorized access, lateral movement, or session hijacking. The introduction of tmux into the SL1 platform adds several critical controls to mitigate these risks: Automatic Session Locking: Idle sessions lock automatically after 15 minutes or immediately upon unclean disconnects. This dramatically reduces the attack surface of unattended sessions. Session Persistence and Recovery: tmux can reattach to previous sessions on reconnect, preserving state without sacrificing security—great for admin continuity. Supervised Access: With tmux, authorized users can monitor or even share terminal sessions for auditing or support—without giving up full shell access. Value for Platform Teams and Security Officers For platform and security leaders, enabling tmux by default means: Stronger Compliance Posture: Session supervision, activity auditing, and inactivity timeouts align with frameworks like NIST 800-53, CIS Controls, and ISO 27001. Reduced Operational Risk: Dropped sessions and orphaned shells are automatically managed—minimizing both user frustration and security exposure. Enhanced Administrator Efficiency: Features like scroll-back search, split panes, and built-in clip boarding streamline complex workflows across systems. In essence, tmux isn't just helping sysadmins—it's helping CISOs sleep better. Risks of Not Using TMUX Choosing not to enable or enforce tmux in enterprise environments comes with hidden but serious risks: Unsecured Idle Sessions: Without timeouts or auto-locks, sessions left open are ripe for misuse or compromise. Poor Session Traceability: Lack of visibility into session states and handoffs creates audit and accountability gaps. Reduced Resilience: A dropped SSH connection can lead to lost work, misconfigurations, or operational inefficiencies—especially in multi-user environments. In contrast, tmux provides a clean, consistent, and secure environment for every shell session—backed by real-world enterprise needs. Final Thoughts The addition of tmux to SL1's default SSH environment reflects a broader industry trend: security is shifting left, right into the command line. For platform teams, this isn't just a convenience—it's a call to action. Enabling tmux is a simple yet powerful way to align with security policies, improve admin workflows, and fortify your infrastructure.118Views2likes0CommentsConvert Customization to PowerFlow Jinja Template
Sometimes when syncing devices from SL1 into ServiceNow as a Configuration Items there can be a mismatch. ServiceNow may list the name as Fully Qualified Domain Name and SL1 will use short name. This setting can be updated in SL1, but in some cases the SL1 team would rather see short name than FQDN. This can be setup on a per SL1 Device Class basis. PowerFlow Using the following Jinja2 “if statement” the device name in SL1 can be converted to use “Device Hostname,” in SL1 instead for Microsoft SQL Server Databases. This excerpt of code would go under attribute mappings for name on the ScienceLogic side mapping to name on the ServiceNow side: {%- set output = [] -%} {%- if (device.device_class|trim) in ['Microsoft | SQL Server Database'] } {%- set output = device.hostname -%} {%- else -%} {%- set output = device.name -%} {%- endif -%} {{ output }} Example:18Views0likes0CommentsEvent Policies and More - Event Management in ScienceLogic SL1
In this video, we explore event policies in ScienceLogic's SL1 platform including how to edit, customize, and create them. You'll learn about event sources, match criteria, and how to manage events using regular expressions, auto-expiration, and suppression. The video also covers the use of power packs for event categorization and monitoring, as well as role-based access control. Learn more about event management in SL1: https://sciencelogic.com Or visit our Support Center for more videos and customer resources.27Views0likes0CommentsEvent Notification and Automation - Event Management in ScienceLogic SL1
In this video, we demonstrate how to respond to events using power packs. You'll learn how to take actions on events, view vital information, run diagnostic tools, and integrate with your service desk. The video also covers role-based access control and automated actions. Learn more about event management in SL1: https://sciencelogic.com Or visit our Support Center for more videos and customer resources.15Views0likes0CommentsEvent Correlation and Masked Events - Event Management in ScienceLogic SL1
In this video, we focus on the masked events column. You'll learn how Science Logic correlates events to highlight the most important ones, masking less critical events to identify the root cause. Learn more about event management in SL1: https://sciencelogic.com Or visit our Support Center for more videos and customer resources.14Views0likes0CommentsResponding to Events - Event Management in ScienceLogic SL1 Last Friday
In this video, we demonstrate how to acknowledge and take ownership of events, share information across the product and service desk, and utilize role-based access control in ScienceLogic's SL1 platform. Learn more about event management in SL1: https://sciencelogic.com Or visit our Support Center for more videos and customer resources.8Views0likes0CommentsEvent Categories - Event Management in ScienceLogic SL1
In this video, we showcase how to categorize and manage events within the system, highlighting predefined event categories, sorting, searching, filtering, and role-based access control. Learn more about event management in SL1: https://sciencelogic.com Or visit our Support Center for more videos and customer resources.10Views0likes0CommentsEvent Insights - Event Management in ScienceLogic SL1
In this video, we explore the Event Insights page in ScienceLogic's SL1 platform, showing how to manage alerts through correlation, deduplication, masking, and suppression. You'll learn how to use filters, automations, and external tickets to resolve issues efficiently. Learn more about event management in SL1: https://sciencelogic.com Or visit our Support Center for more videos and customer resources.9Views0likes0CommentsSL1 Ibiza 12.3.2 Release Notification
We are pleased to announce that SL1 Ibiza 12.3.2 is now available. The release and documentation can be accessed using the following links: https://support.sciencelogic.com/s/release-file/aBtVL0000000pnJ0AQ/1232 If you are planning to consume SL1 Ibiza 12.3.2, be advised of the following: The 12.3.2 release is available only as a patch; there is no ISO version. You can upgrade to this release directly from the following releases: SL1 12.3.0 or 12.3.1 SL1 12.2.1.1 through 12.2.6 SL1 12.1.2, if all of your SL1 appliances have been converted to OL8. If you are on12.1.2, you should upgrade directly to 12.3.2 without consuming the 12.2.x releases. If you are on 12.1.0.2 or 12.1.1, you can upgrade to 12.1.2, convert to OL8, and then upgrade directly to 12.3.2 without consuming the 12.2.x releases. 12.2.x and 12.3.0 STIG-compliant users can upgrade to this release. Users who are on an 11.x MUD system cannot upgrade directly to this release; they must first follow the approved conversion process from 11.x MUD to 12.2.1.1 STIG and then upgrade to 12.3.2 STIG. For more information, see the section on STIG Support. AWS deployments that are using Aurora 3 can upgrade to this release. If you are currently deployed using Aurora 2, you can upgrade to this release but you must perform a post-upgrade Aurora 2 to 3 conversion. SL1 12.3.2 is Department of Defense Information Network (DoDIN)-certified. For more information, see the SL1 Ibiza 12.3.2 release notes.49Views1like0Comments