Vulnerabilities
A vulnerability consists of a weakness or a point of failure that an attacker can exploit. Vulnerability management requires understanding configurations, patches, vendor/contractor management, and the differences between cloud and on-premises IT infrastructure and processes. Addressing vulnerabilities is a process that involves strategic and operational decision-making, making it an essential component of a multilayered approach to mitigate risk, avoiding financial and reputational damages as well as data loss and service disruption.
I’ll write a future page on cloud security with more details. But, as of now, the main difference that must be understood here is the responsibilities between the cloud service provider and the client organization. Typically, the latter must manage vulnerability aspects from the hypervisor up, while on-prem infrastructure demands care from the hardware up to the software. This responsibility can vary following different service models (e.g., IaaS, PaaS, or SaaS) and levels of privacy (private, public, or hybrid clouds). Additionally, cloud services encompass easy access, providing agile maintenance, often from one console. This, however, can lead to single-point-of-failure situations, increasing vulnerability. So, the ease and cost-effectiveness of cloud services must nonetheless be accompanied by sound security practices.
Configuration management is another essential requirement when dealing with vulnerabilities and pertains to different domains of IT, ranging from default credentials to unsecured protocols and open ports.
- Default credentials: newly purchased software or hardware often come with default credentials, which are easily guessable since the username and password are pretty simple, if not absent. These must be immediately altered for strong credentials;
- Excessive privileges: the least privilege principle establishes that an individual within an organization must have the minimum privileges necessary to execute their role. Otherwise, an attacker may exploit these to execute privilege escalation and access sensitive systems and networks;
- Excessive complexity often happens in medium to large organizations, where a large IT inventory leads to system sprawl and undocumented assets. This management gap may neglect critical vulnerabilities, creating opportunities for network or system exploitation and infiltration;
- Relying solely on security through obscurity is another vulnerability, especially in large organizations, where secret management becomes relatively ineffective. Security procedures and techniques are robust when resilient to attacks, including those where secrets may be easily accessed, but the attacker must still overcome other security measures;
- Failing open instead of failing securely may be exploited. This is most evident in situations where software wasn’t correctly programmed to deal with exceptions or memory overload, leading it to disclose sensitive system information, providing privileges, or disrupting system functioning;
- Unsecured protocols are a vulnerability often used against old systems or organizations unaware of sound cybersecurity. A good example is with web servers that interact with clients using HTTP protocol instead of its encrypted counterpart, HTTPS. This logic may extend to many of the old protocols and their more recent versions, such as FTP and FTPS, IMAP and IMAPS, and NTP and NTS;
- Ports that aren’t essential to an organization’s operation must remain closed. Open ports may be identified by an attacker’s scanners and exploited for network infiltration for further attacks or as a doorway for denial-of-service attacks. Judging which ports must be open and which must be closed is central in determining an efficient and secured operation;
- Organizations must use the most recent and open encryption algorithms, developed and peer-reviewed by the cybersecurity community. They must refrain from developing their algorithms since proprietary rights may lead to potential failures being neglected.
Another important aspect regarding vulnerabilities is patch management. It’s strongly recommended that organizations monitor for potential vulnerabilities and patches developed and released by vendors, implementing those as soon as they are released. Vendors often have regular roll-ups, like what Microsoft does. Patches may be categorized as hotfixes (minor updates for specific problems), service packs (a collection of cumulative hotfixes), and updates (typically addressing both critical or non-critical and non-security issues).
On the topic of patch management is zero-day vulnerabilities. They are vulnerabilities that are unknown to everyone, even the vendor. An attacker who knows this may exploit it for unexpected, insidious, and destructive attacks. APTs commonly exploit zero-day vulnerabilities, such as what has been seen in Stuxnet and revealed in the case of the Shadow Brokers.
This kind of vulnerability teaches an essential lesson on a multilayered approach to cybersecurity; by definition, patch management alone cannot address a zero-day gap.
Typically, organizations rely on third-party hardware, software, and services (such as data storage) for their operations. Vendor management is a central strategy for dealing with vulnerabilities from third-party risks. It deals with:
- Correct interoperability between systems and software from different vendors, avoiding introducing new vulnerabilities from this integration;
- Attention to software reaching end-of-life (EOL). This is when a vendor no longer provides support or patches for a typically old product. This makes EOL software susceptible to exploitation, such as the largely and previously adopted Windows XP or Windows Server 2003.
- Awareness regarding vendor security policies and procedures when deciding which products to purchase for organization operation.
