Quickly: What is a Zero-Day security attack? How to strategically tackle it?

What is a Zero-Day Attack?

Definition

In layman terms,

It’s a Zero-Day attack when an attacker exploits a vulnerability in the software that is unknown to its developers.

Severity

Globally, about 95% of the severe security breaches are due to zero-day vulnerabilities. Usually, the application remains zero-day vulnerable for a vaster period. It takes time to discover the vulnerability first and then build the patch, release it, and apply the same. By the time the security patches are there, the zero-day vulnerability would have already caused severe damage to the application, data, and the reputation of stakeholders.

Stages

Any security event has six different stages of the life-cycle. It starts as the vulnerable application code gets installed on the end-users’ machine or the server. A few of the common vulnerability stages are as below.

1. Vulnerable Release
The end-user software application releases with an undiscovered vulnerability (or exploit or security issue).

2. Vulnerability Discovered
Security experts, researchers, ethical hackers have identified unexpected & possibly vulnerable behavior.

3. Vulnerability Disclosed
Experts educate the application vendor or developer about the possible vulnerability. The vendor takes this into account and studies it in detail.

4. Fix Developed, Tested
At times, a security fix may need significant changes in the application and may take months to complete. QA testing also takes the same amount of time.

5. Security Fix Released
The vendor aware the user about the criticality and the importance of the fix. The release is publicly made available.

6. Security Patch Applied
Deployment of the security patch is planned first for the Non-prod machines. After monitoring over weeks, the end-user facing the Production machine gets the fix.

Summary

Any attack is a zero-day attack unless a security patch is developed and tested for an undiscovered vulnerability. Here we refer to those vulnerabilities which are undiscovered by the Software vendor, global community, and the Antiviruses.

How can we avoid it?

No sanitizer or hand-washer making company in this world would claim that their product could protect you from 100% of all the germs out there. Similarly, there is always something undiscovered in Information Technology as well. So the question remains, how do we prepare for it or how do we avoid it.

Approach 1: For consumer-facing, public applications

Apart from the coding best practices, networking, and platform hardening activities, below are some strategic items that one can consider.

1. Project a more extensive period for the ALPHA and BETA releases.
2. Give enough time to the global community to explore and report any vulnerability well in advance.
3. Adopt the multi-services/multi-layer architecture that can have maximum servers within the DMZ.
4. If you use RedHat Linux, ensure that SE Linux policies are in place and running.
5. Double ensure that software release is vulnerability proof before making it generally available for all the users.
6. Use application monitoring tools to identify any unexpected flow/behavior of the incoming requests.
7. Many vulnerabilities may not impose any direct threat to the application stack. However, it may gain access through the legacy software/hardware platform stack and exploit from the same. It is advisable to exclude the support for platforms that are older than four years.

Approach 2: For business-facing, internal/intranet applications

I think no one should ever ignore the standard coding, networking, and OS hardening activities even for the internal applications.

1. At the network level, no software library or the infra component should have direct internet access.
2. Manage internal repositories where only the tried and tested software libraries and toolsets are available for any internal development.
3. Focus more on security than the UX. I guess this trade-off does not harm any internal applications that are bound to be used only by the internal employees/vendors.
4. If available, prefer LTS (Long Term Support) releases of any software/library. These days, software vendors release an LTS every two years. These LTS releases get software patches for five years or more. This way, without much development changes, security can still uphold.
5. Ensure that no internal application is in production without HTTPS/SSL certificates.
6. Never miss out on Vulnerability scans. You never know when your application stack is starring at a treat of death.
7. Set up application and network monitoring for the application stack. You can at least be sure that the application is behaving as expected.

Conclusion

Well, information security is a never-ending topic regardless of a zero-day attack or not. An engineer must understand that in this beautiful world, some dark shadows are hungry to exploit a weakly planned, managed, and developer application stack. Always give equal importance to security, right from the day you are staring up — be it internal or external-facing public application.

Give this article a few claps if you find the above information well-articulated and useful. Have a creative and productive day ahead! :)