Identify>Asset Management>External information systems are catalogued
No systems can exist in isolation. Don’t get taken advantage of by someone else’s system. What exactly is an external information system? According to NIST CSRC glossary, it is “An information system or component of an information system that is outside of the authorization boundary established by the organization and for which the organization typically has no direct control over the application of required security controls or the assessment of security control effectiveness.”
External information systems are catalogued: Defined
You’d think that everybody in IT (and InfoSec) would be aware of external systems. They’d probably appear a little foreign to everybody and they’d also (usually) require some special configuration in order to play well with the internal IT assets. That might not always be the case. Connections to external systems have a weird habit of propagating throughout your org.
The challenge is two-fold. The first facet of the problem relates to who your internal systems are connected to. The second is how they are connected. Each part relates to a fact that is difficult to accept: You can’t control everything all the time.
Suppliers are a primary culprit when it comes to unexpected connections to external systems. Many industries make extensive use of supplier system interconnection. One prime example is retail, where merchandisers and wholesalers automatically stock shelves for their customers, and that’s facilitated by the retailer’s inventory system talking directly to the supplier’s order system. Another is the use of consulting or other specialized service firms, who often use portals (that they developed and own) to store your data. Both are business strategies designed to retain you as a paying customer.
And while we’re talking about customers, you might have a few. And they’re probably accessing your systems too. Your accounting system might talk directly to their payment system so that you can do away with that pesky manual invoicing process or a hundred other uses.
Which leads to the first problem with this item: Any given integration into your information system could start from just about any part of the organization. Procurement, sales, IT, finance, operations—you name it, you could probably dream up a use case for one of their stakeholders needing to connect their system to your system.
In addition, we’ve been wiring systems together for a long time. There are so many mechanisms that you can use to get two systems to talk with each other, that it is almost impossible to figure out a way to govern all of them. Something as complex as an EDI implementation has a bunch of opportunities for control, but what about web scraping? It’s a primitive technique, but it still fits the definition of one system talking to another, and there isn’t exactly a plethora of ways to regulate it, either as the scraper or as the scrapee.
The bottom line: Eexternal systems connections are a vulnerability for your systems and theirs. Where you have an external connection, you should see a suite of control activities pop up around them, but your analysis isn’t done at that point. Ask whether there is a system on the other side of the connection.
External connections abound.
External information systems are catalogued: In the news
In this area, retail organizations tend to come up quite a bit. Retail has experienced a lot of consolidation, and it is almost impossible for an acquirer to fully understand every single detail about how their target operates. At least that was the problem with a 2018 Lord and Taylor breach.
During the breach, a bad actor got in through an external system, which was managed by a vendor. The sales system, as you might imagine, had a very broad profile and was the perfect ingress to utterly (reportedly) compromise the entire company. At the root of the problem was the fact that the breach came hot on the heels of an acquisition of Lord and Taylor by Saks Fifth Avenue.
External information systems are catalogued: Failed…what am I going to see?
The is another foundational control activity, meaning that other activities cannot be relied upon unless this one is working well. What you’ll experience in the case of failure here won’t be obvious. It’ll look like something else: weird external connections, sporadic and unpredictable outages, and regulatory findings.
TechRepublic photo as conceptual art.
Nobody is wiping their feet before they come in.
When people don’t wipe their feet after they walk in the door, it might be about them. But it might also be about you, about your quality as a host(ess). It is your house after all and you should set expectations for your guests.
Companies are no different. If you don’t have a handle on who is connecting to your network, it is a good bet that they aren’t wiping their feet either. You’ll probably see external-facing connections to unusual IP addresses, or use ofing protocols that aren’t encrypted, or maybe they’re pulling (or pushing) inordinate amounts of data. When you find them, investigate them and catalog them. This means the cybersecurity requirements probably were not defined in the contractual agreement—and even if they were, then the requirements, roles and responsibilities for providers of external system services have not been adequately communicated.
You get to deal with everybody else’s problems.
Connections to external information systems offer you a rare pleasure: 80% of the vulnerability with 0% of the control! Do you find yourself relying on the uptime of a supplier data feed? Congratulations, when it goes down, you can pick up the phone and complain, you might even get some form of liquidated damages via the contract, but you aren’t going to solve anything.
Anything that might actually address the issue, e.g., upgraded network hardware (at the vendor side) or secondary sources of connectivity, or one of any number of actual solutions aren’t available to you. You don’t own the external information system but that doesn’t matter much, because you don’t even necessarily know it exists. And you can’t control what you don’t know about because you haven’t maintained a catalog of these external connections.
Regulators won’t stop mumbling about “fourth- party risk” and you have no idea why.
Regulators take interest in the oddest things. You’d think they’d be fixated on. . .government things. On the contrary, they often focus elsewhere. In some interested, they’re really interested in vendor relationships. If you find yourself in one of those industries (banking, healthcare, or a bunch of others) that is highly regulated, you won’t last long if you don’t understand your connections to external systems.
Regulators know that we’re all connected. They think about it so much that they actually make– up imaginary ideas like “fourth- party risk.”. This means that you not only need to know about your external connections, but you also need some idea about who is connecting to your connections——six degrees of Kevin Bacon-style. One thing to keep in mind:– rRegulations always expand. They never shrink. So if you haven’t seen this, hold tight. You haven’t seen this yet.
External information systems are catalogued: Is stellar. . .what does it look like?
Vendor management is a respected and well-resourced area.
A vendor management team is the front line when it comes to tracking your external system connections because the security incidents stemming from external systems historically originated with suppliers. They’ll begin much of the due diligence for suppliers and will usually give the thumbs up on whether the supplier is up to snuff.
A good vendor management program is quite an asset. If you’re looking for some hints on what they look like,. they:
- Have an (at least semi-formal) intake for new vendors
, - Apply a reasonable diligence process
, - Perform to a reasonable cadence
, - Have some authority to shut down a vendor deal if it isn’t safe,
- Can tell you the number of vendors in process vs complete vs waiting.
Vendor management groups are often viewed as an overhead. But if you have a good one, you have a pretty good shot at a reliable listing of connections to external systems.
Pop quizzes aren’t obvious failures.
Pop quizzes are a way of stressing processes to understand how they’ll perform. If from time to time your network scanner finds a connection, and you can actually trace it back to your listing…—congratulations! That’s exactly what you want.
That implies a lot. The chances of missing an external connection are pretty high, so getting one right is pretty impressive. It also implies that entries are being added to the list in a timely manner, and trust levels are defined for the flow of information transferring networks as part of the overall boundary defense strategy.
Notifications from external parties are processed routinely without incident.
Getting a notification from an external party that they’ve had an incident and that your infrastructure was exposed is always fun. They’re usually fire drills, but can sometimes devolve into crises. A big part of surviving these exercises (and there’ll be more than one or two!) is having a good understanding of your environment and being able to leverage it to localize problems and respond.
If you are handling notifications quickly and without a lot of drama, the chances are pretty good that you have this listing embedded robustly somewhere in your process. These notifications trace their way from the business –side of the organization all the way to the technical side and have a habit of generating heat and sound. The listing of external system connections is one important aspect of making it all fit together.
Remediating or implementing external information systems catalogs.
Catalogs of external information systems are difficult to just “whip up.”. Catalogs, like all inventories, tend to improve with age. Entries are added and removed over time and the list is refined. If you’re just starting out, look at your vendor listing, your intrusion detection scans, and your internal software inventories.
Start with your vendor listing (and integrate).
We’re always trying to get the biggest bang for the buck. In this instance, IT risk is the “bang” and the time and effort required to finish everything is the “buck”. So, we’re going to try to get the most critical connections cataloged as quickly as possible.
Usually, the riskiest connections relate to vendors rather than customers. So go through vendor records to figure out who has connections (or is likely to) and who does not. If this isn’t in your vendor records, . . .work to remediate. In any case, you should be able to get a few key leads.
Evidence of external information systems (really) should show up on your scans.
Most companies pay through the nose for intrusion detection-focused software (“IDM”). External connections should stick out in these systems like a sore thumb. If they don’t, it is time to start asking some questions.
If your sensors don’t see any external connections, they might be explicitly configured to exclude them. Or said differently, a vendor might ha’ve come online in the recent past, and generated an alert in the IDM. The alert was resolved by authenticating the connection and subsequently adding a rule to the system that suppresses future alerts. That might actually be a goldmine because all similar rules might be good candidates for your catalog of external information systems.
Internal software inventories can give you clues.
Your internal software might also give you some leads. Enterprise software often phones home to get updates or to return telemetry. Not getting updates is a problem. Sending data unknown to mystery IP addresses is probably worse. But there can be other ways to look at your internal software.
Often, we use our internal software to push or pull data to other systems. Going through your software inventory and coming to understand what each application is accomplishing will likely point you to some additional connections. API keys, FTP connections, and others tend to turn up all over the place.
External information systems are catalogued: Other sources of authority.
COBIT5 APO1-0.04, APO02.02, and DSS01.02
ISO27001:2013 A.11.2.6
NIST 800-53 Rev 4: AC-20 and PL-8
Chatting about “External information systems are catalogued.”
External information systems are catalogued: Resources for the journey.
An Introduction to APIs by Cooksey
“Choosing the Ideal API with Security in Mind” by Johannson
Comments are closed