Written by: Charlie Gero VP & CTO of the Enterprise Division at Akamai
- The new norm
Both the complexity of software and the rate at which end users demand new features continue to grow rapidly and without bounds. In order to satisfy the needs of end users in the time frames required, developers must rely on a rapidly growing set of available libraries, language ecosystems, and third-party infrastructure and services. As a result, larger and larger portions of the functionality of any piece of software is composed of components the developers themselves may never have touched or understood fully.
In any software dependency graph, vulnerabilities are inherited from leaf nodes, or shared code and services, upward to the root node, or the product being programmed. As more and more of these leaf nodes are added to a project, as is necessary per the above, so too does the risk of a vulnerability increase.
This all leads to an inevitable conclusion: These types of vulnerabilities are not only here to stay, but will continue to expand in frequency and impact.
This is the new norm.
- Risk is recursive
We often incorrectly think of risk with respect to the systems, software, and functions we can directly control. More advanced organizations are beginning to assess risk one level out; for example, by asking their developers to examine the trustworthiness of a given library.
But, as more and more systems and software continue to be composed upon layers and layers of third-party code, organizations will increasingly have to not only assess the risk of a given library or partner, but also the practices of that development community or vendor, to ensure they are examining their dependencies as well.
Every node in the dependency tree and supply chain should be assessed by you, your partners, and/or the respective development community to determine if tolerable risk levels are met.
- Visibility unlocks speed
Even with the above risk assessments in place, vulnerabilities are going to occur. We must accept this fact. The question is how we can more effectively address the situation when it happens, not how we can prevent it altogether.
To that end, visibility is paramount. Many organizations struggle with patching because they don’t know what machines are affected in the first place. Enterprises must have systems in place that provide visibility into what is running in the data center and cloud.
The more comprehensive and accurate the visibility is, the faster an organization can react and patch necessary assets.
- Filter out the obvious
Many vulnerabilities can only be attacked through a chain of exploits. Cutting off any piece of the chain is often enough to prevent full exploitation. As a result, systems that filter out both prior and obvious attacks are critical.
Organizations should prioritize the following systems:
Endpoint protection platforms (EPP) – Protect endpoints from known malicious software
- Web application firewalls (WAF) – Protect web applications from known malicious payloads and threat actors
- DNS firewall – Protect endpoints from visiting malicious domains and filter out malicious DNS payloads
- Secure web gateway (SWG) – Protect endpoints from downloading malware and visiting malicious sites on the internet
- Multi-factor authentication (MFA) – Reduce the risk of stolen credentials allowing access into your enterprise where an exploit chain can be delivered
- Identity-based segmentation – Restrict software and systems to communicating with only those machines necessary to complete their tasks
- Zero Trust Network Access (ZTNA) – Limit the impact of infected end users coming into the network
- Least privilege reigns supreme
Finally, organizations should fully embrace the principle of least privilege. Lock down servers, machines, and software so that they may reach only the systems required to perform their tasks.
For example, many of the systems that are making outbound LDAP calls as part of the Log4j exploit never had a need to utilize LDAP. Such systems should have firewalled access to LDAP. Another example: If a service only answers inbound requests, block outbound connections.
By applying the principles of least privilege to all systems and software in your control, you can greatly reduce the threat surface when a vulnerability arises, and in many cases, stop the attack chain before you are impacted.
