Security – Linux.com

Achieving Log Centralization and Analysis with Open Source SIEM and XDR: UTMStack

Linux.com Editorial Staff — Fri, 19 Jan 2024 02:03:57 +0000

Log centralization and analysis are crucial for organizations in troubleshooting system errors, identifying cybersecurity threats, and adhering to various regulations such as The Health Insurance Portability and Accountability Act (HIPAA), Gramm-Leach-Bliley Act (GLBA), Payment Card Industry Data Security Standards (PCI), Cybersecurity Maturity Model Certification (CMMC), and more. While contemporary SIEM solutions have simplified log management, features like threat intelligence and advanced event correlation are often restricted to paid, closed-code systems. This article will walk you through deploying log collectors, a comprehensive log management solution, and correlation rules using UTMStack, an open source and free SIEM and XDR solution, for effective threat detection, system error identification, and automated remediation.

Technology and Architecture Overview

Deploying UTMStack for log centralization and analysis involves three main components: log collectors aka agents, a central server for log centralization, and correlation rules for detection and incident response.

Agents: These collect logs from systems and execute local and remote incident response commands. Agents can also function as proxies for collecting syslog and netflow logs from network devices.

Central Server: This server stores and correlates logs from various assets like other servers and firewalls to identify potential threats and orchestrates incident responses across the IT ecosystem.

Correlation rules and Incident Response: These detect possible threats to system security and availability by correlating logs from multiple systems with threat intelligence and predefined malicious sequences of behaviors and compromise indicators. Once a correlation rule evaluates a group of logs as potentially malicious, an alert triggers the incident response command.

Deploying the Open Source Security Stack

Log Centralization Server

The log centralization server can be deployed using an ISO image from the utmstack website for simplicity. For advanced installation options, please visit the official GitHub repository https://github.com/utmstack/UTMStack

Here are the instructions for installing without the ISO on Ubuntu Linux 22.04 LTS.

After installation, access the server via a browser using the server’s IP address or DNS name and the random secure password provided by the installer.

Deploying Log Collectors

Navigate to the “Integrations” section and select the appropriate agent for your operating system. Additional integrations can be configured as needed.

Defining Correlation Rules and Incident Response

Correlation rules form the core of a log management system, defining which logs or combinations thereof should trigger an alert or incident. UTMStack uses these rules as a basis for Incident Response playbooks.

Let’s take, for instance, a brute-force attack. This type of cybersecurity threat attempts to guess a user’s password by trying massive random combinations of characters until the correct sequence matches the user’s credentials. These types of attacks usually leave behind a trail of logs that indicate a user has failed to log into a system several times in a short period of time.

You can access the complete list of prebuilt correlation rules and the guide to creating new ones from the official UTMStack repository. For this guide, we’ll create a sample correlation rule to detect brute-force attacks.

UTMStack correlation rules are written in plain YAML and have three main components. Threat documentation that describes the rule, defines a tactic category of attack, severity and name of the rule. The second component is the logic and frequency block, where the rules for triggering this alert are defined. Finally, the alert information block, where the information is extracted from the logs and saved into the alert item.

These YAML rules can be saved as text files and copied into the correlation rules folder via the Web User interface. Any rules uploaded there will be processed by the correlation engine automatically.

All logs the system receives are aggregated and correlated for indicators of compromise (IOCs) using several open threat intelligence feeds. This feature is enabled by default, and there is no need for custom correlation rules or configurations.

Finally, to deploy the incident response playbooks, navigate to the incident response automation section and drop a command to disable future login attempts from the offender host. This can be done by blocking its IP in the firewall or disabling the victim user until further investigation can be done.

UTMStack’s Incident response commands use dynamic variables to handle the execution of commands with different targets. Here are some examples.

Command to block a user:
usermod -L ${source.user}

Command to block an IP
iptables -A INPUT -s ${source.ip} -j DROP

Summary

Log centralization and analysis are essential for security, availability, and compliance. Open source tools can deliver advanced flexibility and rich feature sets to meet complex use cases and deliver an enterprise-ready experience. The UTMStack open source project is a powerful SIEM and XDR system that can deliver log management, threat detection and incident response by correlating and aggregating logs in real-time. Advanced features such as IOC detection, threat intelligence, and compliance are built-in features of the security stack.

Join Our Community and Contribute

We’re always looking for passionate individuals to contribute to our project. Whether you’re a developer, security expert, or just enthusiastic about cybersecurity, your input is valuable. Here’s how you can get involved:

GitHub Repository: Visit our GitHub repository to explore our code, submit issues, or contribute enhancements. Your code contributions can help us improve and expand UTMStack’s capabilities.

Discord Channel: Join our Discord community to discuss with fellow contributors, share ideas, and collaborate on projects. It’s a great place to learn from others and contribute your expertise.

Online Chat and Forums: For quick questions or discussions, use the online chat feature on our official website or the forums. It’s a direct line to our team and community for real-time interactions.

Your contributions, big or small, play a crucial part in the development and improvement of UTMStack. Together, we can build a stronger, more secure open-source SIEM & XDR solution. Join us today and help shape the future of cybersecurity!

Author

Rick Valdes
Founder, UTMStack

The post Achieving Log Centralization and Analysis with Open Source SIEM and XDR: UTMStack appeared first on Linux.com.

Critical Bluetooth Flaw Exposes Android, Apple & Linux Devices to Takeover

Linux.com Editorial Staff — Thu, 07 Dec 2023 12:33:39 +0000

Attackers can exploit a critical Bluetooth security vulnerability that’s been lurking largely unnoticed for years on macOS, iOS, Android, and Linux device platforms. The keystroke injection vulnerability allows an attacker to control the targeted device as if they were attached by a Bluetooth keyboard, performing various functions remotely depending on the endpoint.

Creating a ‘Minimum Elements’ SPDX SBOM Document in 5 Minutes

Linux.com Editorial Staff — Wed, 03 May 2023 15:20:22 +0000

The rise in cyberattacks and software’s critical role in our lives has brought to light the need for increased transparency and accountability in the software supply chain. Software distributors can achieve this by providing software bills of materials (SBOMs), which provide a comprehensive list of all the components used in a software product, including open source and proprietary code, libraries, and dependencies.

In May 2021, United States Executive Order 14028 on improving the nation’s cybersecurity emphasized the importance of SBOMs in protecting the software supply chain. After comprehensive proof of concepts using the Software Package Data Exchange format (SPDX), the National Telecommunications and Information Administration (NTIA) released the “minimum elements” for an SBOM. The minimum elements require data fields that enable basic use cases:

Supplier Name
Component Name
Version of the Component
Other Unique Identifiers
Dependency Relationship
Author of SBOM Data
Timestamp

The NTIA recommends that the data contained in these fields should be expressed in predictable implementations and data formats to enable automation support. One of the preferred formats for expressing this data is SPDX. While version 2.3 of the SPDX specification, released in November 2022, was the first version to explicitly describe how to express the NTIA minimum elements in an SPDX document, SPDX has supported these elements since its version 2.0 release in 2015.

Read more about how to create an SPDX SBOM document that complies with the NTIA “minimum elements” at The New Stack.

The post Creating a ‘Minimum Elements’ SPDX SBOM Document in 5 Minutes appeared first on Linux.com.

Introducing self-service SPDX SBOMs

Linux.com Editorial Staff — Wed, 29 Mar 2023 23:02:23 +0000

Following the precedent set by Executive Order 14028, security and compliance teams increasingly request software bills of materials (SBOMs) to identify the open source components of their software projects, assess their vulnerability to emerging threats, and verify alignment with license policies. So, we asked ourselves, how do we make SBOMs easier to generate and share?

Read the rest at the GitHub blog

The post Introducing self-service SPDX SBOMs appeared first on Linux.com.

Why you should use SPDX for security

Linux.com Editorial Staff — Tue, 10 Jan 2023 19:21:51 +0000

By Phil Odence

Software Package Data Exchange® (SPDX®) is a standard format for describing a software bill of materials that supports a range of use cases, not least SBOMs to manage security vulnerabilities.

SPDX has been an open project under the auspices of the Linux Foundation for over a decade, all the time with the purpose of describing software content. More recently, SPDX became an ISO standard. (https://www.iso.org/standard/81870.html) Well ahead of its time, SPDX was initially designed with an eye toward license compliance but has also become a standard for supporting security use cases as recognized by the Cybersecurity and Infrastructure Security Agency (CISA).

Arguably, the most complex use case is including license and copyright information about software packages. This is because legal ownership can apply to the package, files within, and even a small collection of lines of code. To fully support such usage, that standard needs to be able to handle the granularity, which is also needed for some security use cases. Additionally, legal analysis requires a standard, immutable list of licenses, their text, and ways to express complex licensing situations. So, SPDX includes a collection of licenses (also adopted by other projects) and a license expression language.

From early in the days of the project, there was interest from some corners in a lighter version that was more straightforward, allowing companies to get started providing package license information in a standard format. The standard evolved to specify a core set of required fields and a superset range of optional fields. This concept laid the foundation for “profiles” currently being defined, different sets of optional and required fields required for a given use case. Another key dimension of SPDX’s evolution was adding relationships and references to external documents. This was originally developed with the idea of linking different SPDX docs to allow, for example, the structure of an SPDX description to mirror the structure of the software it describes. The core capability, though, allows for linking to other types of documents and is critical for support linking and SBOM to associated security information.

The recent ramp in interest in SBOMs has been focused on the security use case, driven by the general climate of cybersecurity risk and, more specifically, by the US government’s intent to require SBOMs of vendors. SPDX has been moving in this direction for some time, and the specification includes the functionality to support it. In 2016, version SPDX released version 2.1, which included specific external reference fields for the security use cases. The current 2.3 version was specifically aimed at increasing security support, and a key profile planned for the 3.0 release targets this use case.

SPDX utilizes the external reference capability of SPDX and adds new reference categories to support linking to security documents. The spec’s Annex K: How To Use SPDX in Different Scenarios https://spdx.github.io/spdx-spec/v2.3/how-to-use/ goes into detail and provides examples of how to link to various vulnerability-related resources, including CPEs, CVEs, VEX information including CSAF-formatted security information, code fixes, and other information. There is also a section mapping the NTIA minimum elements to the corresponding fields in SPDX.

SPDX 3.0, currently under active development, extends the concept of profiles introduced in 2.2 and has one specifically designed for security. With 3.0, SPDX documents will embed more context for the linked security data, allowing tool efficiency.

Profiles are sets of required and optional fields for a specific use case. So whether a document conforms to the spec will be relative to a use case. For example, a security-oriented SBOM may not have the features required to comply with the legal profile but on the other hand, could have all the required fields to comply with both. A core profile will include a minimal set of elements to describe a software package, corresponding roughly to what has previously been referred to as SPDX Lite. Beyond that, then, will be several profiles, including Security, Legal, and others, such as one for AI apps or one that includes build information.

One important external reference will be to CISA Vulnerability Exploitability eXchange docs, an envisioned machine-readable, vendor-supplied assessment of vulnerabilities in their software. VEX is still a bit of a moving target, and multiple “flavors” seem to be arising without a standard having been nailed down. In any case, SPDX 3.0 will support it. Additionally, based on input from various open source projects, the group is considering incorporating a simple set of minimal security elements as optional SPDX fields in the Security profile. This would not be a new alternative to CSAF or VEX but rather a lightweight way for projects, not set up to go deep, to provide the basic security info common to all vulnerability description formats.

A challenge remains for anyone exchanging SBOMs (in any format) concerning unambiguously referencing software elements. One SBOM’s “Log4j” is another’s “Apache Log4j.” It’s a similar issue to the one SPDX solved for license references. A loose analogy: If airlines were to share flight schedules without agreeing on how to refer to London Heathrow, they’d be useless. This can’t be solved locally to SPDX, as it’s needed for other formats and applications. The group believes there may be a solution in the combination of Package URL (PURL) for components associated with package managers and CPEs and SWID for commercial software components. Support for OmniBOR (Universal Bill Of Receipts) has also been added to SPDX 2.3, another possible solution to uniquely identifying software components.

SPDX has demonstrated a solid foundation and the ability to evolve to meet users’ evolving needs. The introduction of profiles allows for considerable flexibility. Recently a constituency has started up a functional safety (FuSa) profile. The subject of hardware has come up for discussion as well, and the spec may one day be referred to as System Package Data Exchange… SPDX.

SPDX Myths

SPDX can’t support security.

False. SPDX currently supports linking to security information, and that capability will be extended for a broader range of use cases in the future.

SPDX is old and complicated.

Partially True. The team would say “well-established.” “Complex” might be a better word than “complicated,” and so is the set of problems it addresses. And with optional fields, SPDX Lite and profiles, it can be as simple as it needs to be and still address the problem. The architects of SPDX have taken the long view to build the flexibility to handle an uncertain future.

SPDX is not human-readable

Partially True. SPDX supports various formats, including a very human-readable spreadsheet for simple examples. It gets most challenging with XML and JSON, which depends on the human. But the reality is to describe software of any size and do anything useful with the information, machines need to be involved, and human eyes would only slow the process.

SPDX doesn’t support VEX.

Mostly false. Today SPDX documents can make external reference to VEX and VDR documents. We are in the camp of people who believe that is the best way to support VEX. Because SBOMs and knowledge about the vulnerabilities in contained components move a very different pace, we don’t think it makes sense to expect that information is always included in the SBOM document.

SPDX is only for license compliance.

False. OK, it depends on when the statement was made. Ten years ago… True.

SPDX is not a format for describing SBOMs.

False. It is.

SPDX cannot describe hardware BOMs.

True… today. The format is flexible enough to evolve in this direction in the future, and it is currently being explored.

The post Why you should use SPDX for security appeared first on Linux.com.

Open Source Software Security: Turning Sand into Concrete

Jason Perlow — Fri, 20 May 2022 01:41:42 +0000

Last week I had the privilege of participating in the Open Source Software Security Summit II in Washington, DC. The Linux Foundation and OpenSSF gathered around 100 participants from enterprise, the U.S. government, and the open source community to agree on an action plan to help increase the security of open source software.

If you were to look at the attendee list, you would likely be struck by the amount of collaboration among competitors on this issue. But, it isn’t a surprise to the open source community. Security is an excellent example of why organizations participate in open source software projects.

This is organizations coming together on a joint solution to a common problem so they can focus on innovating.

A question I often receive when I tell people where I work is, Why would for-profit companies want to participate in open source projects? There are lots of reasons, of course, but it boils down to organizations coming together on a joint solution to a common problem so they can focus on innovating. For instance, film studios coming together around software for saving video files or color management or the finance industry improving trader’s desktops or web companies supporting the languages and tools that make the web possible. And these are just a handful of examples.

Security is everyone’s concern and solutions benefit everyone. As one summit participant noted, “My direct competitors are in the room, but this is not an area where we compete. We all want to protect our customers, shareholders, and employees. . . 99% of the time we’re working on the same problems and trying to solve them in a smarter way.”

99% of the time we’re working on the same problems and trying to solve them in a smarter way.

Everyone is better off by sharing vulnerabilities and solutions and working together towards a common goal of a more resilient ecosystem. No company is immune, everyone relies on multiple open source software packages to run their organization’s software. It is no surprise that competitors are working together on this – it is what the open source community does.

As we gathered in DC, my colleague Mark Miller talked to participants about their expectations and their perspectives on the meeting. When asked what he hoped to accomplish during the two day summit, Brian Fox of Sonatype said, “The world is asking for a response to make open source better. We are bringing together the government, vendors, competitors, [and] open source ecosystems to see what we can collectively do to raise the bar in open source security.”

We are bringing together the government, vendors, competitors, [and] open source ecosystems to see what we can collectively do to raise the bar in open source security.

Another participant painted a picture which I find especially helpful, “I remember the old saying, we built the Internet on sand. I thought about that, underscoring the fact that sand is a part of concrete. This process means that we have an opportunity to shore up a lot of the foundation that we built the Internet on, the code that we’re developing. It is an opportunity to improve upon what we currently have, which is a mixture of sand and concrete. How do we get it all to concrete?”

Enterprise companies and community representatives were at the summit, as well as key U.S. government decision makers. The high-level government officials were there the entire day, participating in the meeting, and listening to the discussions. Their level of participation was striking to me. I have worked in and around government at the policy level for 25 years – and it is more common than not – for government officials to be invited to speak, come and speak, and then leave right after they deliver their remarks. To see them there one year after implementing the Executive Order on Improving the Nation’s Cybersecurity and engaged signals the importance they place on solving this problem and the respect they have for the group that gathered last week Kudos to Anne Neuberger, her team, and the others who joined from around the U.S. government.

By the end of the first day, agreement was reached on a plan, comprised of 10 key initiatives:

Security Education Deliver baseline secure software development education and certification to all.
Risk Assessment Establish a public, vendor-neutral, objective-metrics-based risk assessment dashboard for the top 10,000 (or more) OSS components.
Digital Signatures Accelerate the adoption of digital signatures on software releases.
Memory Safety Eliminate root causes of many vulnerabilities through replacement of non-memory-safe languages.
Incident Response Establish the OpenSSF Open Source Security Incident Response Team, security experts who can step in to assist open source projects during critical times when responding to a vulnerability.
Better Scanning Accelerate discovery of new vulnerabilities by maintainers and experts through advanced security tools and expert guidance.
Code Audits Conduct third-party code reviews (and any necessary remediation work) of up to 200 of the most-critical OSS components once per year.
Data Sharing Coordinate industry-wide data sharing to improve the research that helps determine the most critical OSS components.
SBOMs Everywhere Improve SBOM tooling and training to drive adoption.
Improved Supply Chains Enhance the 10 most critical OSS build systems, package managers, and distribution systems with better supply chain security tools and best practices.

The full document, The Open Source Software Security Mobilization Plan, is available for you to review and download.

Of course, a plan without action isn’t worth much. Thankfully, organizations are investing resources. On the day it was delivered, already $30 million was pledged to implement the plan. Organizations are also setting aside staff to support the project:

Google announced its “new ‘Open Source Maintenance Crew’, a dedicated staff of Google engineers who will work closely with upstream maintainers on improving the security of critical open source projects.”

Amazon Web Services committed $10 million in funding in addition to engineering resources, “we will continue and increase our existing commitments of direct engineering contributions to critical open source projects.

Intel is increasing its investment: “Intel has a long history of leadership and investment in open source software and secure computing. Over the last five years, Intel has invested over $250M in advancing open source software security. As we approach the next phase of Open Ecosystem initiatives, Intel is growing its pledge to support the Linux Foundation by double digit percentages.”

Microsoft is adding $5 million in additional funding because, “Open source software is core to nearly every company’s tech strategy. Collaboration and investment across the ecosystem strengthens and sustains security for everyone.”

These investments are the start of an initiative to raise $150M toward implementation of the project.

Last week’s meeting and the plan mark the beginning of a new and critical pooling of resources – knowledge, staff, and money – to further shore up the world’s digital infrastructure, all built upon a foundation of open source software. It is the next step (well, really several steps) in the journey.

If you want to join the efforts, start at the OpenSSF.

The post Open Source Software Security: Turning Sand into Concrete appeared first on Linux Foundation.

The post Open Source Software Security: Turning Sand into Concrete appeared first on Linux.com.

Enhancing Supply Chain Security for Embedded Systems: Renode Dashboard for Zephyr RTOS Adds New Software Bill of Materials (SBOM) Capabilities by Default

Linux.com Editorial Staff — Mon, 31 Jan 2022 18:52:09 +0000

Authors: Michael Gielda, Kate Stewart

A Software Bill of Materials (or SBOM) makes the information about the software components running on a system available. Transparency and summarization are needed in embedded systems with resource constraints and where updates may have significant deployment or recall costs.

In 2021, we saw significant indicators that having an SBOM is going to become a regulatory requirement in some embedded market segments (medical, energy, etc.) and the US Government came out with an executive order in May 2021 that has a timeline with expectations that the industry would be ready for generating SBOMs in 2022.

Software Package Data eXchange® (SPDX®) is an international standard (ISO/IEC 5962:2021), able to express SBOM information, as well as other facts about software packages, files, and snippets. It is uniquely able to specify the fidelity of information required for embedded software, and partition the information logically to express system level information.

The Zephyr Project incorporated the ability to generate SBOMs automatically during builds in 2021. This is done when building Zephyr executables using the ‘west spdx’ command. West is Zephyr’s meta-tool that supports the build infrastructure. There are multiple SBOMs created (one for the Zephyr sources, one for the application sources, and one for the built image) that will link back to all the dependencies in the source files.

Antmicro’s Renode Zephyr Dashboard now includes SBOMs

A Platinum member of Zephyr Project, Antmicro, among other contributions (including maintaining Zephyr support for RISC-V and work around supporting Zephyr on FPGA platforms), has been ensuring Zephyr developers can access powerful simulation, testing, and debug capabilities of their open source simulation framework, Renode.

Renode shares the vendor-neutral and user-centric approach of Zephyr, focusing on the security and developer productivity of the RTOS.

The two open source projects have been collaborating for many years now, but recently a great showcase of where Zephyr and Renode complement each other is demonstrated by the Renode Zephyr dashboard.

The Renode tool visualizes the results of a continuous integration (CI) system running real Zephyr binaries on multiple architectures, boards and SoCs from a variety of vendors, incorporating the advantages of portable examples and the structured platform data provided by Zephyr.

Renode’s flexibility and reconfigurability produces a concise dashboard displaying Zephyr-compatible boards currently supported in Antmicro’s open simulation framework.

This dashboard project utilizes the systemized information from Zephyr – which uses device trees to describe the platform data needed to pick and configure specific drivers and subsystems, which can then be mapped onto the plug and play, building blocks oriented nature of Renode.

Renode Dashboard Includes SBOMs in Standard Builds

As a member of the Zephyr’s Technical Steering Committee, Antmicro collaborates with other Zephyr members (which include many of Antmicro’s customers such as Google, Intel, or NXP) to ensure the use of a standardized and unified approach to implementing new ports. This concept of defining commonalities in platforms is an important step toward improving and generalizing support for silicon in embedded systems tooling.

Currently at 129 passing boards and spanning four different demos, including MicroPython and TensorFlow Lite Micro, the most recent version of the Zephyr Dashboard is enhanced with the ability to generate SBOM artifacts for all of its samples automatically.

This showcases how simple Zephyr makes it to generate reliable and accountable software and have accompanying SBOMs. The dashboard shows a breadth of platforms supported by both Zephyr and Renode, all of which have SBOMs.

Using Renode helps you track various metrics (performance, coverage, memory use etc.) related to your software across time. The software BOM generation capability complements this picture, providing the traceability and security needed to build real-life commercial products.

About the Authors:

Michael Gielda is VP Business Development at Antmicro, Chair of Outreach for CHIPS Alliance, and a member of the Marketing Committees in RISC-V International and The Zephyr Project. Contact: mgielda@antmicro.com

Kate Stewart is VP Dependable Embedded Systems at The Linux Foundation, a technical co-lead in the SPDX project, and a governing board member for the CHAOSS project. Contact: kstewart@linuxfoundation.org

The post Enhancing Supply Chain Security for Embedded Systems: Renode Dashboard for Zephyr RTOS Adds New Software Bill of Materials (SBOM) Capabilities by Default appeared first on Linux.com.

Download the 2021 Linux Foundation Annual Report

Linux.com Editorial Staff — Wed, 08 Dec 2021 23:42:44 +0000

In 2021, The Linux Foundation continued to see organizations embrace open collaboration and open source principles, accelerating new innovations, approaches, and best practices. As a community, we made significant progress in the areas of cloud-native computing, 5G networking, software supply chain security, 3D gaming, and a host of new industry and social initiatives.

Download and read the report today.

The post Download the 2021 Linux Foundation Annual Report appeared first on Linux.com.

Microsoft’s Dapr Becomes CNCF Incubation Project

Swapnil Bhartiya — Wed, 08 Dec 2021 23:34:49 +0000

Microsoft recently contributed its Dapr (Distributed Application Runtime) project to CNCF, which has been accepted at the foundation as an incubating project. We sat down with Dapr founder Mark Fussell to learn more about the project.

The post Microsoft’s Dapr Becomes CNCF Incubation Project appeared first on Linux.com.

Understanding Security In The Cloud Native World

Swapnil Bhartiya — Wed, 08 Dec 2021 23:31:37 +0000

CNCF Security TAG recently conducted a micro-survey to better understand cloud-native security. We sat down with Brandon Lum, CNCF Security TAG Co-Chair, and IBM Research Engineer to talk about the micro-survey and deep dive into how the security landscape has changed are people are embracing cloud-native technologies.

The post Understanding Security In The Cloud Native World appeared first on Linux.com.