Can you secure your organization if you aren’t aware of which internet-facing applications you own?
Not effectively.
There are many organizations that have never gone through a full security audit. Even though they know which public network address ranges they own, they have no idea of everything that exists on those ranges. They have documented some systems, but between configuration changes, new technologies, and shadow IT, they do not know exactly what is on those ranges. Therefore, they do not know their entire internet-facing exposure.
If your company only has partial documentation of internet-facing applications, or has not performed such an audit recently, your first task should be to discover those externally-facing services and systems as they exist now. But how can you do that? Let’s find out.
What Are Internet-Facing Applications?
Internet-facing applications are programs and services that are accessible from the internet, as opposed to only through an internal network.
Companies set up internet-facing applications for several reasons. Sometimes, they are necessary to interact with customers or partners. In other cases, they are necessary for employees who are either working from home or from out in the field.
Examples of internet-facing applications include web applications, APIs, SSH servers, VPN gateways, cloud services, internet-facing firewalls, or any other remotely accessible services that are either deliberately or accidentally placed on an internet-facing server. Internet facing assets can reside on-premises, in the cloud, or any combination of hosted, managed, or virtualized infrastructure.
Why Identify Internet-Facing Applications?
Quite simply, without keeping a complete and frequently-updated inventory of internet-facing applications, you do not know what data is potentially vulnerable and how attackers may target your organization. Many categories of cyber attacks begin with an external attacker gaining a foothold in an organization through an initial compromise of an internet facing application.
Real attackers, such as Sandworm Team, Magic Hound, and Axiom, keep track of critical vulnerabilities and use a range of techniques to compromise internet-facing applications. The most commonly relied upon techniques for all forms of cyber vulnerabilities, including the exploitation of public-facing applications, are cataloged by MITRE ATT&CK.
MITRE suggests a number of mitigation tactics, including regular software patching, exploit prevention (such as a WAF or IDS/IPS), and vulnerability scanning. Your goal is to determine the best methods to secure your network and keep your data from getting into the wrong hands. Without knowing your internet-facing applications and what data they can access, you cannot effectively map out your attack surface. Without that knowledge, you cannot accurately manage your risk and secure your business.
How to Identify Internet-Facing Applications
For businesses that have never mapped out their attack surface, or have not attempted to map it out in a long time, this task may seem daunting. However, thinking of this process in steps can make it more approachable. Then, you can build those steps into your ongoing security procedures in order to ensure discovery and securing of internet-facing servers and applications remains part of your security defenses.
The process may not necessarily be difficult from a technical perspective, but it becomes an involved and continuous process to maintain up-to-date knowledge of your systems inside your organization. It requires communication, diligent data collection, and careful data analysis. There are also many products and services available to help with these tasks.
To help you identify the internet-facing applications in your organization, these are the things you need to know:
- Know Yourself
Identify the assets important to the business. - Know Your Team
Identify where the assets sit on your network and other services provided by your organization through information gathered from other departments. - Know What the World Knows
Attempt to find your public-facing systems. We will discuss the DNS reconnaissance and network scanning techniques in this blog. - Know How to Collect and Access Discovery Data
Organize the information obtained from the previous steps. - Know What Lies in the Cloud
Determine your responsibility with respect to external assets and information hosted by a third party.
Cloud Security
Know Yourself
Start this process by talking with different business groups in the organizations, and establish what your assets are. It begins with asking about the core concerns of your company:
- What do you do?
- What is your main source of revenue?
- How do certain services and data contribute to these goals?
- How would the compromise of particular services or data undermine these goals?
This exercise will not only help you to identify and prioritize key assets but will also open a communication channel with other groups not usually involved in ensuring software security. Both of these achievements will make security projects now and in the future go more smoothly than ever, thanks to that improved communication.
Know Your Team
Once you have a picture of your asset categories and priorities, find your organization’s Network Engineer. They can help you answer important questions, especially when it comes to the essential focus of firewalls.
Firewalls protect the perimeter of the network, guarding your internal data from external attacks. Firewalls are a default-closed technology, which means if a user, either accidentally or on-purpose, creates a service in your network, it won't be exposed to the internet unless the firewall is instructed to allow it. If your firewalls are correctly configured, only the internet facing applications are explicitly allowed by the firewall. This is also a great source of information for creating an internet-facing application asset list, an essential resource to refer to in the event of a breach.
There are some exceptions that are important to address, and your Network Engineer can help identify whether any of them apply to your organization. These firewall security exceptions include:
- Applications that are not behind a firewall, either intentionally or unintentionally. Even if there is a sound reason for not placing certain applications behind a firewall, it’s essential to identify them on the internet-facing application asset list so that teams know where to look in the event of a breach.
- Firewalls work at the protocol level, which means that if a protocol is allowed, most firewalls are not able to distinguish which instances of the application are allowed so long as they operate on the same protocol. In order to fully assess which applications are exposed, you need to identify not only those that were intentionally allowed but also those that may have been unintentionally allowed under the same protocol.
- Tunnels, VPNs, and Netbonds are interfaces that connect networks together. Therefore, anything on the other end of a tunnel is likely a separate network that would have its own separate firewall perimeter.
- Anything that operates outside your network can still have internet facing applications. This can include external cloud environments, services, and applications that your organization may be unaware are owned by you but hosted elsewhere on the internet.
There are more scenarios that could be addressed, but this builds a foundation for securing internet-facing applications. This makes sure you know what you are looking for, including information about routing, network flow, and an approximate number of devices or nodes to expect on the network.
This discussion offers multiple benefits. You are getting to know the colleagues you will be working with to help implement your security policies and also creating a communication channel for when you do send a request to modify a firewall policy, request SNMP log information regarding open services, or have certain network traffic monitored.
Know What the World Knows
Ideally, you may want to run four sets of scans, one to determine what TCP ports are open and maybe apply a simple banner grabbing technique to determine possible port information. You also want to perform UDP port scanning even though it takes noticeably longer because it is a connectionless protocol. The ports to scan will depend on previous knowledge obtained from your Network and System Administration teams.
DNS Reconnaissance
Knowing and cataloging which domains your company uses is a strong starting point, though this goes further. DNS Reconnaissance should include knowing what information a DNS lookup on your company reveals, finding out what security limitations are placed on zone transfer requests, identifying mail servers, websites, and addresses associated with your business, and tracking ownership of those assets.
WHOIS records also provide searchable data sources for the owners of domain names. The expiry of domain ownership is an especially important bit of information for attackers, since expired domains can be claimed, or may hold unmaintained applications. Performing DNS reconnaissance is an important step in identifying your internet facing applications, because it is also the starting point for many attackers.
Certificate Transparency Reconnaissance
TLS certificates are used to identify a host and bind a cryptographic key to the hostname, allowing users to establish an encrypted connection that is verified by a certificate authority. The global certificate authority infrastructure has created a public transparency log that is required to create and sign valid TLS certificates. This provides a log of all TLS certificates created globally.
This data, when carefully analyzed, can help discover if someone in your organization is creating certificates or hosts outside of the usual procedure. This can also be a useful threat intel datapoint if an attacker is attempting to create lookalike domains, or otherwise targeting your TLS infrastructure.
Host and Port Detection
This begins with knowing and cataloging the IP ranges that belong to your company, including IPv4 and IPv6. Then, use a tool such as NMAP to scan those IP ranges and detect what hosts and services exist on that range. Consider establishing an external host from which all external discovery scans are performed, and then whitelisting that scanning host in the firewall or IDS, so you can get a true external view of available services. This should be done on a regular basis in order to identify new or changed hosts.
NMAP is used to detect ports and services that are running on identified hosts. NMAP allows a broad range of scanning options including TCP services, UDP services, and more detailed script scans that enumerate services in more detail. These essential scans should be conducted simultaneously with the host detection scans mentioned above. This information allows you to identify expected and unexpected services, investigate unexpected services, and figure out which services should be taken down or built into updated firewall or IDS configurations.
It’s crucial to remember that these scans should not be one-and-done. Rather, host and port detection should be an ongoing process that identifies any changes to the internet-facing exposure and allows your team to make adjustments accordingly.
Attack Surface Mapping
In addition to network services, web applications are a large part of an external attack surface. Mapping that part of the attack surface requires regularly assessing web applications for OWASP Top Ten vulnerabilities, as well as others that connect to what threat groups are using to attack web applications.
This verification can involve web-specific vulnerability scanners, as well as manual application assessment from security experts who specialize in web application assessment. The more detailed and thorough you are up front, the faster and more efficient future queries will become.
For a company of any size, discovering the external footprint is a large data collection project. Gathering that data is necessary, but it also matters to collect and keep this data in a scalable and accessible form. That way, you can track and respond to changes as you scan your internet-facing applications and services weekly, bi-weekly, or as often as your information security policy deems fit.
Know How to Collect and Access Discovery Data
Discovering what the world knows means little if you do not also log and track that information in a way that allows you to take action and increase your security. There are multiple ways to do this.
For small data sets, one useful way is to parse the information in Comma Separated Values (CSV) format and add it to a spreadsheet with various pages based on scan date. You may need to do some scripting to parse the information in a way that is meaningful to you.
An example would be to use PowerShell, Python or other scripting language to parse the output of the various data sources and aggregate it into a meaningful format. This can then give you a searchable and visual way to read and compare footprint data.
Larger datasets may require different tools. More and more data points can be aggregated from threat intel, OSINT and infrastructure management and monitoring tools. The data processing and management for an organization’s assets and exposure mapping can quickly become a full time job. There are also commercial services that automate much of this effort and provide a searchable interface of the results.
There is no single right way to keep track of scan data — just ensure that the data is well documented, easily retrievable, and presentable when the moment requires it.
Know What Lies in the Cloud
As you move more data and services into the cloud, knowing what is there and what internet-facing services those cloud operations require becomes crucial. Knowing your cloud attack surface and your level of responsibility requires performing the following tasks:
- Identify the cloud services your business is using.
- Identify what data is associated with each of those cloud services.
- Identify what internet-facing services are required to interact with those cloud services.
- Be aware of the relationship your cloud service provider has with you, including their implementation of shared responsibility.
- Know what security testing is consistently performed by the cloud services provider.
- Know what security testing is or is not allowed to be performed by your organization.
- Understand the security configurations that are available for each cloud service, and use that knowledge to document and apply a proper security policy for each application or service.
A lot of organizations utilize the cloud in some way. The external service or application is still considered a public-facing entity of your organization. As part of your attack surface mapping, thoroughly tracking every cloud element optimizes your processes for future queries.
The level of responsibility you have for those services changes based on the type of service you are using. For example: are you using Infrastructure as a Service (IaaS), Software as a Service (SaaS), or Platform as a Service (PaaS)? In most cases, there is a level of shared responsibility between your organization and the cloud service provider, and there are also often rules for what security testing is allowed or not allowed by a cloud provider. In all scenarios, it is still your responsibility to ensure due diligence is done to identify risks in the cloud and secure your data.
Next Steps to Strengthening Your External Security Posture
Discovering, tracking, and hardening internet-facing applications is part of a strong security foundation for businesses of all sizes. After all, when you know what attackers outside your company can see, you can prioritize and complete projects to shrink what they can see, remediate vulnerabilities, and make it more difficult for those attackers to get in.
Designing a plan to reduce external attack surface can be difficult, but it can be easier with a partner who has deep security experience. To learn more about how Kroll can assist you with assessing your external security posture, or with testing a specific facet of your environment such as web applications, begin the conversation today.
