How Can You Identify Your Internet-Facing Applications?

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, web servers, SSH gateways, VPN gateways, cloud application delivery platforms, internet-facing firewalls, or any other remotely accessible services that are either deliberately or accidentally placed on an internet-facing server instead of behind a VPN or firewall.

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 available and how attackers can get in.

Real attackers keep track of critical vulnerabilities and use a range of techniques to compromise internet-facing applications. Your goal is 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.

To help you identify the internet-facing applications in your organization, these are the things you need to know:

1. Know yourself :  Identify the assets important to the business.
2. Know your team :  Identify where the assets sit on your network and other services provided by your organization through information gathered from other departments.
3. 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.
4. Know how to collect and access discovery data :  Organize the information obtained from the previous steps.
5. Know what lies in the cloud:  Determine your responsibility with respect to external assets and information hosted by a third party.

1. 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.

2. 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, including:

• How many nodes/devices do you have on the network?
• Does your network segregate traffic from your servers and workstations?
• If so, how is it implemented? I.E. with virtual local area networks (VLANs)?
• What is your current routing setup?
• What is your current domain name (DNS) setup?
• Do you have any firewalls or intrusion detection/prevention systems in place? If yes, what are your current policies for them?
• How are you keeping track of device information, especially on routers?
• How are you logging all that information?
• Are you implementing Simple Network Management Protocol (SNMP) to monitor the network? If so, what information are you logging?

There are more questions that could be asked, but this builds a foundation. 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.

Once you have talked to the network administrator, sit down with your systems administrator or the systems administration team. If you now have a rough idea of how many devices are on your network and how the traffic flow should be, your system administrator can help you determine what services are running on those systems and what servers and clients you may have on the network.

Things you may consider asking your system administrator:

• What operating systems do your servers use? (Windows, Linux, Solaris, BSD, etc.)
• Which services or applications do you have running on these servers?
• What web applications is your company running, and where are those applications hosted?
• How are you managing these servers?
• How are configurations, changes, and server management procedures documented?

As usual, there are many more questions that could be asked and discussed with your System Administrator, but the main concerns are what operating systems you are running, what possible services may be installed, and how they are managed.

This type of information is not only useful for the initial external scanning but will be helpful when implementing solutions to any issues that arise.

3. 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.
• Host Detection: This begins with knowing and cataloging the IP ranges that belong to your company. Then, use a tool such as Nmap to scan those IP ranges and detect what hosts 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.
• Port Detection: Nmap can also be 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. This information allows you to identify expected and unexpected services, investigated unexpected services, and figure out which services should be taken down or built into updated firewall or IDS configurations.
• Web Application 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 can involve web-specific vulnerability scanners, as well as manual application assessment from security experts who specialize in web application assessment.
• Database Detection and Mapping: Behind many web applications lie a database. Attack groups use software such as sqlmap and Havij to automate SQL injection attacks and gain access to information in databases with vulnerable interfaces. Thus, an integral component of mapping out your attack surface is to identify vulnerabilities in your databases.

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.

4. 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 (Microsoft scripting language) to parse the xml output of an Nmap scan and convert it to CSV format with meaningful headers. This can then give you a searchable and visual way to read and compare footprint data.

Larger datasets may require different tools. Another way to track scans can be through Zenmap, the Graphical User Interface (GUI) to Nmap, which allows for clean views of hosts and services found during scans.

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.

5. 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 asking the following questions:

• 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 or is not allowed on cloud services.
• 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.

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 the cloud service provider and you, 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 Security Compass Advisory 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.