June 28, 2022 By Michael Thompson 4 min read

It might be cliché to say that security is critical for enterprises, but that doesn’t make it any less true.

Across the IT landscape, security is a multifaceted exercise. Security in depth is the concept where security best practices are applied at every level of IT — including networks, operating systems, databases, applications (purchased or developed) and physical access to machine rooms, server racks and buildings. Advanced techniques like intrusion detection, penetration testing (sometimes called “white hat hacking”) and threat monitoring have become standard at large enterprises and government entities.

Patch currency remains a challenge for parts of the software stack

While these advanced practices are absolutely critical to maintaining a strong security posture for the enterprise, there remain areas where foundational security practices are not always rigorously applied. One foundational practice is keeping the software stack up to date with the latest software levels and security patches. Keeping software up to date, particularly in the middleware and application space, can lag behind — sometimes significantly. 

This is due to a variety of factors — the human time cost of applying updates, the risks and test effort required from breaking changes in the software (typically from version-to-version incompatibilities), the old adage of “if it ain’t broke, don’t fix it” and other organizational priorities superseding the software patching and maintenance process. Being behind on software security patches (or worse, being on old, outdated versions of software that no longer receive such patches) increases an organization’s threat risk.

Essentially, “patch currency” is a critical software security practice, and delays in the security patching process increase an organization’s threat exposure. Efforts to remain current are often hampered by the burdensome effort it puts on the teams who maintain the software. The operations teams are required to test and deploy the updates, and the development teams are required to react to new versions and breaking changes.

For enterprises to be agile and secure — without placing an undue burden on these teams — they need to select technologies that are secure by design, provide rapid updates in response to software vulnerabilities and deliver frequent, easy-to-consume updates to their software.

Solutions from Software as a Service (SaaS) providers have alleviated much of this concern, as the responsibility for maintaining the security of the software that underpins the service is the responsibility of the SaaS provider and is enforced with SLAs. However, for software that remains on-premises and managed by software operations teams, the challenge persists. Operating system vendors like Microsoft, Red Hat and Canonical have been delivering strong software patching and update capabilities over the past few decades. In contrast, seamless security updates for middleware and applications have received less attention.

This is one of the many spaces in which IBM has been investing. With IBM’s long track record on security — from world-class security on the Z mainframe to the long-standing X-Force capabilities — and with the recent announcement of the acquisition of Randori, IBM’s commitment to security is clear.

Within IBM Automation, we’ve unleashed our creativity to apply automation to key pain point areas that we understand from the general market and from our customers.

Automation will ease the burden faced by teams

The top reported pain point is the burden of patch currency for middleware. The burden of the effort means teams are inhibited from spending time on strategic initiatives. At the heart of this pain point is a lack of automation and a lack of visibility across the variety of deployments for which teams are responsible. The lack of visibility often correlates to a weakened security posture, as visibility is necessary in order to understand what attack surface exists for a given software product or application and thereby understand what actions are necessary to maintain a secure posture. In order to reduce the burden of the security patching process, a combination of automation (to reduce cycle times and human burden) and increased visibility (to ensure required actions are taken and updates are applied successfully) is required.

Automation will help teams achieve continuous security by reducing the burden and cost to maintain software. Practices like vulnerability assessment, tracking and remediation can be automated to reduce or remove labor-intensive, repetitive tasks. There are various software solutions that focus on specific aspects of patch currency, but very few bring together a comprehensive view that is actionable by the actual team responsible for the work. 

Typically, security scanning tools and expertise is centralized within an organization and then actions are “pushed down” to owning teams. This can create delays and silos of information that create suboptimal workflows and split responsibility. A more efficient approach is to have tools that deliver actionable insights to the responsible operations and development team(s), with reporting capabilities to key stakeholders like executives and compliance teams.

Innovations from the WebSphere portfolio will ease continuous security compliance

The WebSphere portfolio has evolved to help our customers alleviate the burden of maintaining a strong security posture for the WebSphere deployments, enabling them to achieve continuous security compliance in two key ways: Liberty continuous security updates and IBM WebSphere Automation.

WebSphere Liberty and Open Liberty: It has never been easier to keep your application server up to date with the Liberty runtime. Open Liberty and the commercial version, WebSphere Liberty, deliver updates every four weeks. These production-ready software updates include the latest security fixes, performance enhancements and new capabilities which can be rapidly deployed with minimal effort. Liberty’s zero-migration policy, which is a commitment from IBM to not regress application APIs or server configuration, and Liberty’s features-by-configuration model mean that the latest Liberty update can be deployed confidently without risk of breaking your application deployments.

IBM WebSphere Automation: IBM is offering WebSphere Automation to simplify the way operations teams work with automation to proactively automate the protection, health and optimization of your WebSphere estate so that your teams can focus on the work that matters the most. Automate your existing IBM WebSphere security and operational activities to reduce the cycle time of threat remediation, so your threat exposure is minimized and your business and most critical assets are protected. Stay on top of the latest security threats with automation for vulnerability detect, remediation and compliance tracking.

Was this article helpful?
YesNo

More from Automation

Deployable architecture on IBM Cloud: Simplifying system deployment

3 min read - Deployable architecture (DA) refers to a specific design pattern or approach that allows an application or system to be easily deployed and managed across various environments. A deployable architecture involves components, modules and dependencies in a way that allows for seamless deployment and makes it easy for developers and operations teams to quickly deploy new features and updates to the system, without requiring extensive manual intervention. There are several key characteristics of a deployable architecture, which include: Automation: Deployable architecture…

Understanding glue records and Dedicated DNS

3 min read - Domain name system (DNS) resolution is an iterative process where a recursive resolver attempts to look up a domain name using a hierarchical resolution chain. First, the recursive resolver queries the root (.), which provides the nameservers for the top-level domain(TLD), e.g.com. Next, it queries the TLD nameservers, which provide the domain’s authoritative nameservers. Finally, the recursive resolver  queries those authoritative nameservers.   In many cases, we see domains delegated to nameservers inside their own domain, for instance, “example.com.” is delegated…

Using dig +trace to understand DNS resolution from start to finish

2 min read - The dig command is a powerful tool for troubleshooting queries and responses received from the Domain Name Service (DNS). It is installed by default on many operating systems, including Linux® and Mac OS X. It can be installed on Microsoft Windows as part of Cygwin.  One of the many things dig can do is to perform recursive DNS resolution and display all of the steps that it took in your terminal. This is extremely useful for understanding not only how the DNS…

IBM Newsletters

Get our newsletters and topic updates that deliver the latest thought leadership and insights on emerging trends.
Subscribe now More newsletters