Becoming impervious with simple invisibility

Attack surface management is a crucial aspect of Cybersecurity. By reducing the attack surface of your domains, you can optimize the active cyber defense effort significantly.

The increased use of CI/CD strategies has allowed software development teams to deploy code more frequently. This frequent deployment is made possible by testing the code more often, which contributes to a higher level of product quality.

To test their latest code, teams need separate environments for deployment, which is a standard practice to safeguard production environments from faulty code or business logic. This approach gives development teams the freedom to fail and make fixes without impacting their business or customer experience.

However, the advantages of rapid failure and flexible deployments also have downsides.

Due to the high frequency of deployments to development and staging environments, comprehensive security testing of the code may be overlooked in favor of agility.

Protection with Environment Isolation

One of the best practices for these high-velocity deployments is using different cloud accounts or projects. This approach also brings another advantage of reducing blast radius in environments.

In case a release of misconfiguration on cloud components on the development environment does not make a negative impact on production. Any scaling out event on production systems doesn’t create quotas or limit issues for development and staging environments.

But every advantage comes with its cost. This cost is an explosion in the number of cloud accounts and projects to implement security monitoring and protections around these environments.

What does that mean?

Naturally, all of the testing cannot be accommodated as part of respective environments. Some of these testing activities have been performed by using SaaS platforms to achieve efficiency and using expert knowledge on specific topics.

To be able to set up these external testing platforms, you must expose your development and staging environments similar to your production environment even though nobody is hitting other than your testing setups and malicious actors looking for exploitable resources.

Yes, you heard right.

You are not alone in using your development and testing environment endpoints exposed to the Internet. As soon as you create a virtual machine or a load balancer, its public IP address starts getting some kind of hits from robotic IP scanners or SSH Brute force attempts continuously.

Unless you set up logging and monitor the traffic hitting that IP address, you stay completely unaware of the situation.

All these malicious traffic are completely generic until an exploitable vulnerability is detected. Then the situation becomes completely different than generic traffic. Let’s dive in a little bit more.

Your domain name increases your attack value

All cybersecurity professionals know that the value of assets is important for Threat Modelling practices. If a valuable asset is exposed it will get more attention from malicious actors.

Now, you may ask what is the relation between asset value and the public IP address of a virtual machine?

Let me explain.

If the resource you are exposing also gives out clues related to your business domain name, the value of the resource increases based on the value of your business.

The value of your business determines the volume of malicious traffic you will receive in all your environments linearly or sometimes exponentially.

How will they know the endpoint?

Under normal circumstances and as part of our daily routines we see the traces of IP or Port scanner bot activities on our security monitoring tool logs regularly. They blindly scan if there are any active hosts and if they detect them, another set of bots starts testing the detected systems for known weaknesses and vulnerabilities.

None of these scanning bots can find out which domain or business uses these discovered hosts on the internet.

Many other platforms can be used out of their purpose to discover the attack surface of a business or target domain.

One of the platforms is Certificate Transparency Logs.

But what are they?

When a development team needs a new SSL/TLS Certificate for their service or product, they get this certificate from an accredited public Certificate Authority. All these certificate authorities are sharing issued certificates as part of a transparency purpose.

As taught during many application security courses, you can use these transparency logs to check the footprint of a domain or a business. And it is really easy to access.

You can see these logs by yourself by clicking the example.com link. You can see all the historical SSL/TLS certificates of a domain and its all subdomains.

You can test for your domains by changing the domain name in the above link to see what you are exposing.

Ways to defend

Here we are coming to the part of what we can do for defending our attack surface and business footprint.

We have several options.

If your service and product deployments are Cloud-based and follow cloud-native strategies, you can leverage the Web Application Firewall (WAF) functionality of your cloud provider. This way, you can protect your deployed workloads against OWASP Top 10 attacks very easily. You can configure these WAFs for each of your environments on different strictness levels.

Let me explain a bit more. While you are protecting your production environment against more general threats, your development and testing environments can implement an IP range whitelisting approach to reject public internet traffic and only allow legitimate traffic.

This way you can get a certain level of invisibility against these scanners and also malicious actors with a simple configuration setting. I know this may mean extra work but it is better to be safe than sorry.

Another way is to disconnect or separate your development and testing environment domains from production or business domains.

Let me elaborate a bit more.

Your development teams can register separate domains for their development and testing environment consisting of random character strings like “c0aabd61f48c476f8838113959f4320f.com”, “8b85d8023c694b56a6fe49012a03666f.net”, “169a6b30ae3f42e68ee35e1b30fe813d.net”, “a6186d06061c4aeca453e7502bdcda91.com”.

These are easy to generate. Generate a UUID, remove hyphens, and add a TLD. Then you have completely obfuscated domains for your non-production environments.

If you keep a WAF configuration to these obfuscated domains, you can have a more rigid defense for your development and testing environments.

These two are the most common practices that I suggest to development teams. But there are many more and different strategies, tools, and approaches.

Thank you for staying with me up to this point in this post.

If you have some other practical thoughts and ideas about applicable security in all aspects, feel free to comment or send message to me.