meta name="publicationmedia-verification" content="a1495fac-4a0b-4066-ba36-cd0fdba2335c" meta name="publicationmedia-verification" content="3613a74d-ad4f-45e3-9c0c-8227540b2cf0"
Tech

Misconfigurations and vulnerabilities of storage and continuity

A team of storage and data protection experts founded the company in 2005 with one mission in mind – to provide enterprise security and IT leaders with the cyber resilience solutions they need to ensure critical data is constantly protected.

By securing both on-premises and cloud storage systems, Continuity helps enterprises protect their data against cybersecurity threats.  

By adding a layer of security to your existing data-protection solutions, Continuity’s StorageGuard prevents attackers from entering your storage systems and accessing your data.

The ContinuityTM solution gives 60% of the top US banks the peace of mind that their storage systems can withstand ransomware attacks.

A brief overview

In order to provide a unique insight into storage security, we analyzed data from a large number of storage risk assessments. In addition to Dell EMC, IBM, Hitachi Data Systems, HPE, Cisco, Brocade, NetApp, and others, the analyzed data covers multiple storage vendors and models. 

SAN / NAS, storage management servers, storage appliances, virtual SAN, storage network switches, data protection appliances, storage virtualization systems, and other storage devices were analyzed.

Our analysis of over 6,000 security misconfigurations revealed recurring patterns and important security considerations many organizations fail to address.

There are four main categories of misconfigurations:

  1. Infractions of security configuration guidelines by storage vendors
  2. CIS, NIST, PCI DSS, and other compliance frameworks violated.
  3. CVEs (Common Vulnerabilities and Exposures) identified for storage
  4. Deviations from community-driven best practices (gathered and generalized from dozens of enterprise security baselines for storage – representing shared community insights)

Protocols or settings used in storage that are vulnerable

Both traditional networking protocols (IP over Ethernet and WAN) and dedicated fibre-channel storage protocols are supported by storage protocols.  During session establishment as well as during data exchange, it is imperative to secure those protocols.  Many environments, however, still suffer from configuration gaps such as:

  • A failure to disable legacy storage protocols, or even worse, defaulting to their use (e.g., SMBv1, NFSv3)
  • Using cypher suites no longer recommended (e.g., allowing TLS 1.0 and 1.1, disabling SSL 2.0 and 3.0) – some of which must be disabled to comply with regulatory frameworks (e.g., PCI DSS).
  • Managing, replicating, and backing up critical data without encrypting it.
  • As well as many others (allowing cleartext HTTP sessions, using unsecure SNMP community strings, etc.)

 2. Storage CVEs that remain unaddressed

For storage devices and storage networking, there are a variety of software components that get updated from time to time, including:

  • Operating systems specifically designed for storage arrays and network switches (proprietary or highly specialized versions of commercial or open-source operating systems)
  • The firmware of the controller
  • Software suites for management
  • Storage connectors for virtual environments, for example, API servers

Common Vulnerability and Exposure (CVE) records are published for such devices on an ongoing basis as vulnerabilities are discovered.  It is usually recommended to upgrade or change the configuration to fix the problem.  Most vulnerability management tools used by organizations and enterprises do not detect many storage CVEs (but rather on server OS, traditional network gear, software products), and close to 20% of storage devices are exposed.  The environments covered in this study contained more than 70 different CVEs (of course, there are many more out there).

Issues with storage access rights (overexposure)

There are several levels of configuration for access control to storage:

  • Access to storage elements, such as block devices, network shares, or even individual files and objects, should be mapped only to designated components (e.g., applications or hotspots).  Device filtering (e.g., share configuration, LUN mapping) and network filtering techniques (e.g., IP filters, SAN zoning and masking) are used to accomplish this.
  • Permissions and ownership (e.g., read, write, modify, ACLs) in relation to the data itself
  • Managed storage capabilities (e.g., replication, snapshot management)

Many devices were affected by improper configuration, including unrestricted access to shared storage, unrecommended zoning and masking configurations, and ability to reach storage elements from external networks.

Authentication and management of users are insecure

Users and roles are used to manage storage devices, and in many cases, access to data is regulated similarly.  For a variety of reasons, storage devices are not held to the same rigor as compute and network elements when it comes to user management and authentication. Among them are:

  • The use of local users for routine operations (instead of approved central user management protocols) was not recommended – default factory accounts were still being used in many cases
  • The use of non-individual admin accounts
  • Session management restrictions are not enforced
  • An improper separation of duties (e.g., same roles managing data and its protection mechanisms – such as snapshots and backups)

Read More About Roblox condo games

Leave a Reply

Your email address will not be published. Required fields are marked *

Check Also
Close
Back to top button