Data Exposure Types: System Information

Last updated by UpGuard on September 3, 2018

There are many different kinds of sensitive data that can be exposed, each with its own particular exploits and consequences. This article will focus on what we have categorized as “systems information,” data that describes digital operations, such as systems inventory, configuration details, data center and cloud design, performance metrics and analyses, application code, and IT business data, such as equipment spend, vendor discount, and budgeting. By better understanding what this data is, why it matters, and what the potential consequences of its exposure are, we can more effectively act to control sensitive information and prevent future data breaches.


Types of System Information

Configuration

One type of system information we have found exposed repeatedly in our research is configuration details for systems and applications. Server inventory sheets, for example, often detail how many servers a company is running, what they do, where they are, what kind of hardware (physical or virtual) they are utilizing, what operating system they have (sometimes including version and/or service pack,) among other attributes. Configuration databases may have entries for much more granular descriptions, such as what ports are open, what software is installed, security settings, associated users and groups, and any other object that can become a configuration item.

Even just basic information like server name, IP address, and function can provide a clear road map of how services function within an organization. With the scale, complexity, and easy sprawl of modern data centers, this type of information is the only way businesses can effectively manage their digital environment. Furthermore, such documentation, the more interactive the better, is the best way to assure standardization across many systems, as well as to monitor progress, vulnerability patching across similar systems for example.

How it Can Be Misused

The best way to understand how exposed data gets exploited is to first understand its business value, and how that value can be siphoned off by unauthorized individuals. Just as configuration data provides IT with visibility into the environment, so too does exposed configuration data open a window to malicious actors interested in understanding a company’s operations. The more information about systems an attacker has, the better able they will be to find weaknesses and compromise them. Without exposing configuration data, hackers might have to dedicate themselves to a lengthy “casing” process to map out where and how to strike. But if that same information is meticulously gathered, aggregated, and then exposed by the entity itself, the bar for exploitation becomes significantly lower. 

Architecture

While configuration information describes every individual system in an environment, system architecture describes the environment as a whole, focusing on the services these systems provide, how they are designed and distributed, and what measures have been put into place for security, redundancy, and availability. Sometimes it can be difficult to see the forest for the trees when digging into the details of enterprise system configuration, but just as important as understanding those details is for individual systems, understanding how they work together-- and more importantly, how they achieve the desired business results-- is the only way to ensure IT resources and efforts are in-line with business goals.

For example, a configuration spreadsheet might detail the names, addresses, and specifications of every server involved in a Microsoft Exchange environment, but an Exchange design document would detail how those systems interact, answering questions like how many systems are clustered in the back end, how many edge systems face the internet and what ports are open on them, which Active Directory accounts have what kind of access to Exchange and what services run under them. Ditto for any enterprise level service that requires the orchestration of multiple assets.

How it Can Be Misused

Configuration details can help attackers find weaknesses in individual systems, but design documents can direct them at where to strike particular services most effectively. Some design documents that have not followed security best practices even include credentials, providing not only the map, but the keys as well. Database connection strings are a particularly sensitive and commonly exposed data point within architectural document sets, often containing root users and passwords in plain text. But even without credentials, systems architecture lays out in perfect detail exactly what attackers need to know to begin a campaign.

Metrics and Analysis

Another type of data we’ve run across are metrics gathered on systems and operations for analysis purposes. These could be performance metrics for systems, activity logs for applications, network traffic analyses, cloud usage statistics, or user authentication records-- anything gathered and aggregated for the purposes of measuring operations. 

Effectively measuring and correcting operations is key to the adaptive agility necessary in a modern digital business. Properly scoping hardware can reduce costs and avoid outages; application monitoring can help understand customer behavior and interests-- there is direct business value in this information, which is why it is gathered in the first place. 

How it Can Be Misused

Metrics provide another set of data points for a potential attacker to exploit. Aside from being another area where plain-text credentials often pop up, metrics provide valuable links to information that might not otherwise be available. The network device names, IP addresses, and ports listed in a network traffic analysis can pinpoint weaknesses, such as the best place to sniff traffic to grab credentials. System performance metrics can expose unpatched and outdated systems, leaving attackers only to choose which exploit to use to break in. Performance metrics also can show how much load systems can bear before failing, a useful bit of information for someone planning a denial-of-service (DOS) attack-- ensuring service is just as much a part of good security as protecting data. Finally, user authentication logs, depending on how much information they contain, can assist in both direct hacking-- by revealing administrative and service accounts otherwise obscured to the public, and indirectly in social engineering, by providing insider information about account details.

Application Code

There are plenty of software companies that need to worry about proprietary code being exposed, but the risks of leaked application code apply to any organization that does in-house development, even of scripts or simple tools. Nearly all major companies rely on software engineers to build out the digital side of their businesses, even if their primary business is selling hammers or trading stocks.

 The applications, tools, and scripts developed by organizations provide much needed functionality for employees and customers. Even out of the box software solutions require a large amount of customization and tweaking to fit into a complex enterprise. Sometimes this development work is contracted, other times engineers are hired directly, but either way, the code itself becomes a business asset, and one with a wide spectrum of risk depending on what the code actually does.

How it Can Be Misused

Much of the in-house code we discover during research contains names, addresses, and even credentials for otherwise internal systems and applications. Organizations who employ or contract software developers often set them to the task of connecting things. Third-party solutions provide much of the functionality necessary for every kind of business, but gluing those disparate solutions together into a coherent environment requires extensive customization. Because of this, the nature of much application code includes information about those crucial third-party solutions, any of which could be exploited with far more ease if this application code is unnecessarily exposed. 

Beyond using the code to jump to other systems, much of the code itself could be considered a trade secret, as it often performs a function integral to business operations, and which was built in-house for proprietary use. Having efficient tools is a clear competitive advantage, unintentionally disclosing what those tools are, how they work, and how to build them removes that advantage. Additionally, the code itself can contain vulnerabilities, either by programming accidents or by employing vulnerable third party libraries and dependencies. Finding these vulnerabilities in exposed code would make compromising the systems they run on much easier.

Conclusion

Data has become a blueprint for a business. The same advantages gained by employing this data within the organization can be turned against it if improperly handled. Systems information does not get the same clout as personally identifiable information, and arguably that makes sense, as PII often involves millions of individuals. But exposed systems information can lead directly to a PII breach, as well as many other problems, like malware, fraud, and resource hijacking for botnets.

There is an existential link between companies and the data they generate and collect. From production workflows, to sales, to payroll, to marketing strategies-- the business is in the information, and the care taken with this information is the care taken with the business itself. Information technology has generated a massive amount of value in the world. It is the responsibility of those taking advantage of this value to protect their customers and themselves against its inherent and unavoidable risks. Doing so will help create a sustainable and resilient digital ecosystem for everyone.

 

Learn why hundreds of companies trust UpGuard to protect their systems from breaches.

Book a free demo