Software is specifically separated. No single enterprise organization, in whatever industry, runs a cookie-cutter standard selection of software applications and data services. Whether because of internal IT departmental policy, whether as a result of mergers & acquisitions that coalesce previously disconnected (often divergent) software stacks, or whether down to the fact that different tech leaders prefer different types of application structures, platforms and infrastructure, an enterprse software estate is nearly always a fairly diverse smörgåsbord.
Cloud–based infrastructure-centric IT, security and compliance solution company Qualys, Inc. says it has recognized the seemingly infinite variety of form and function in software today. As a result, the company is now working to further extend its platform to take into account the uncertainties that stem from these levels of diversity.
Now looking to balance risk diversity with risk management democracy, Qualys is now opening up its platform to software engineering teams to bring their own detections to assess, prioritize and remediate the risk associated with ‘first-party software’ (defined below) and its embedded open-source components.
What is first-party software?
If third-party software encompasses every purchased, bought-in external piece of software – whether it is commercial-off-the-shelf (COTS) standard application fodder, or more bespoke customized higher-end software and services – then first-party software is that which is created, developed, published and deployed in-house by an organization’s own developers.
So first-party software should be really good stuff, right? Yes and no. While first-party software can be beautifully constructed to suit the user requirements of the company’s user base to a precision-engineered fit, there are two sides to this coin. As snugly crafted as it is, first-party, or company-developed software, often lacks the disciplined vulnerability and configuration management practices used for third-party software. It’s simple economics, first-party software doesn’t have to go through as many levels of public usage stress and safety testing, so it often doesn’t.
“First-party applications, being proprietary, often lack adequate risk detection, prioritization and remediation support from scanning tools,” said Sumedh Thakar, president and CEO of Qualys. “Our first-in-industry capabilities enable organizations to leverage the Qualys platform’s capabilities, identifying and analyzing both first-party and third-party software risks to develop an overall TruRisk [see below] score for a comprehensive view of the organization’s overall risk.”
A tricky term to pin down because it is used as a generic label across the IT industry, TruRisk in the Qualys universe is the company’s own-branded term to denote a mode in its own platform that provides data that measures asset criticality, Qualys Detection Score (QDS) and TruRisk Score.
Thakar and team point to wider studies that illustrate how over 90% of first-party software includes open source components, with more than 40% having high risks such as exploitable vulnerabilities.
“Today, application and security operations teams rely on manual checks or siloed scripts to evaluate the security of first-party software, resulting in ad-hoc security assessment that impedes the ability to prioritize and remediate risk effectively. Furthermore, traditional vulnerability assessment or software composition analysis tools do not detect the presence of embedded open source packages across the production environment,” details Qualys, in a technical product sheet.
Software scripts, explained simply
The new Qualys solution enables organizations to bring their own detection and remediation scripts (explained below) created using well-known software languages such as PowerShell and Python to Qualys Vulnerability Management, Detection and Response (VMDR) as Qualys ID (QIDs), which the Qualys Cloud Agent executes in a secure and controlled manner.
While software code is what we all (laypersons included) understand applications to run when they are set to work, a software script bears a resemblance in structure to code. Like code, a script presents a sequence of instructions; however, the differentiating factor lies in the purpose and execution of scripts. Scripts are designed to be ‘computed’ and executed by, on or in another software program. In the example above, an organisation could develop its own independent scripts dedicated to evaluating the strength and robustness of another application. Similarly, a software script might introduce new functionality to an existing software application. Regardless of the application, scripts exert additional control and enable enhanced capabilities within software systems.
“A script, in essence, is a set of programmed commands or instructions that instruct a computer or software program to perform specific tasks or actions. It often involves automating repetitive processes, enhancing functionality, or interacting with other components of a software ecosystem. In contrast to traditional software code that might execute as a standalone program, scripts typically rely on the context of another software program to function effectively,” said Paul Baird, chief technical security officer, UK and North EMEA region at Qualys.
This adaptability makes scripts valuable tools for tailoring software behaviour to specific needs, improving efficiency and extending the capabilities of software applications.
“In our complex enterprise environment, we’ve often encountered situations where our security needs surpassed the capabilities of off-the-shelf software,” said Gabriel Julián Carrera, CISO at Argentinian healthcare provider OSDE. “Consequently, we’ve resorted to pulling together independent scripts to achieve the assessments our unique homegrown solutions require. Qualys’ new offering eliminates this fragmented approach by seamlessly integrating our proprietary assessments and commercial tools into one unified Qualys TruRisk Platform saving us time and helping us stay ahead of potential attackers.”
Qualys TruRisk detects and prioritizes all its findings and reporting in one single workflow. The idea here is for software engineering departments (and AppSec security teams) to be able to use their own detections to identify sensitive content, assess critical process and application statuses, tag assets based on sensitive or Personally Identifiable Information (PII) data presence. All of which should help mitigate risks associated with critical vulnerabilities.
Safer smörgåsbords?
Like their Scandinavian dining counterparts, there’s little chance of software smörgåsbords becoming less diverse in our global world of interconnected influences. Any approach to enterprise software management that takes into account diversity in all its forms generally sounds like common sense. That being said, take it easy on the pickled herring.
Read the full article here
