GraphCube GraphCube
SECURING YOUR DIGITAL RESOURCES
BACKGROUND
Some years ago, I was building a new mobile app for a high-profile international corporation. A key task involved our app invoking an API call to a third-party global data aggregator…which is a technical way of saying “our app was getting data from a company A database and delivering that data to a company B database; we were the technicians who built the bridge to make this data sharing work.” The API specified a standard XML packet-request action including various URI and validation tokens. The request-results would be returned in an XML packet containing data that matched our XML request parameters. During initial testing, our XML request kept failing. The standard error message was non-specific "...could not establish a secure channel..." I re-checked our parameters, ran an internal API-mimic XML request to our servers and then examined the actual request-response syntax from our server. Our server request-response syntax and behavior were exactly as we designed and expected. Following this testing, once again I invoked the API request to the data aggregator and once again the same error message was returned. Frustrating!
After some hours of intense debugging and a few espressos, I found the problem: our internal application software was aborting the API connection (https secure channel) with the data aggregator system because of a security certificate mismatch (think of this response, similar to when you mail a letter and it gets returned to you with the message undeliverable, no such address). My first inclination was that the data aggregator had provided us with incorrect API connection values. I called the data aggregator and explained the error I was receiving and they assured me "...that is not an error we generate and the URI parameters and tokens we gave you are correct." I triple-checked the URI, the connection ports, the API parameters, and validation tokens. Once again, I invoked the API, and yet again the same error was returned. At this point, having eliminated all other variables in the API process, I was confident of the error cause; the data aggregator had secured the API server resources using misconfigured SSL certificates. Misconfigured security certificates can create huge issues but are relatively simple to correct. Why is a simple broken certificate so important? Because misconfigured certificates can break the SSL encryption trust-chain between the sender and the receiver. This break can result in information system security breaches, data/identity leakage, exposure and theft of corporate assets, and loss of business confidence.
To understand a security certificate relationship, allow me to tell a story of how a certificate misconfiguration behaves in everyday terms.
STORY
Suppose you need to mail a folder of private documents from your origin address (home) to a recipient address (destination). We will call this folder the “documents”. First, you need to place your documents into a suitable container (envelope) which we will call a “package.” Next, you need to label your package with 2 parameters; your origin (home) address and the delivery (destination) address; combined, we will call these two parameters your “address variables.” Next, after you have selected and paid a shipper for your package, the shipper attaches a label with a tracking number to your package. We will call your selected shipper the “transporter” and your tracking number your “tracking number.” Your package is now prepared, accepted, loaded into the transporter system and on its way to your destination. If the delivery is successful, you will receive a confirmation of your package delivery from your transporter. Let us call this confirmation the “delivery confirmation.” Here is a visual comparison of your story and my case of the misconfigured certificates.
| Physical | Digital | Explanation |
| Yours | Mine | |
| documents | data | These are the contents of what we are sending to our destination. For your case, the contents are printed documents, in my case the documents are digital data. |
| package | XML | These are the labeled containers that will hold our documents (yours) and data (mine) during transport. |
| origin/destination | URI Variables | These are the locations/addresses for the delivery of our documents (yours) and data (mine). |
| transporter | API | These are the carriers of our documents (yours) and data (mine). For your documents, it is a physical delivery company, for me it is a set of digital delivery instructions included in the API; my delivery is via the internet. |
| tracking number | validation token | The delivery process includes an identifier so the delivery can be tracked. For you, this is a tracking number affixed to your package. For me, this is a digital validation token that is required for delivery; no token or incorrect token = no delivery. |
| confirmation number | return result | For you, this is the delivery confirmation number confirming successful delivery of your package. For me, the response in the form of returned data is my digital confirmation that my API successfully delivered my XML. |
Chances are that you have performed variations of this story many times in your daily life. You should be able to see from above visual comparison that the processes are in many ways very similar in concept. The main difference equates to a physical package in Your case and a digital XML package in My case.
Now let’s see what happens if the process above goes awry. Suppose your package was addressed with destination variable = 101 Main Street San Jose, CA 95110. Inadvertently, the transporter agent delivers your package to 110 Main Street San Jose, CA 95110 and leaves your package in the 110-office designated mail receptacle: process complete. Your transporter records the process as complete and transmits a delivery confirmation status for your tracking number. At this point in the process, there is a mismatch in the printed destination and the physical delivery destination, yet according to the process, all conditions have been satisfied successfully. Several scenarios are possible. Let us examine one of the more critical scenarios. First, when an occupant at 110 retrieves your package, they may or may not (inadvertently or intentionally) open the package and view the contents of your documents. If and when this happens, your documents have been compromised, exposed, and your privacy and control have been breached; your documents no longer belong to you nor your intended recipient. This is a serious process failure.
With this story in mind, imagine My case in the digital realm where multiple threat vectors constantly search for any weakness in a transport process (API). When a weakness like an SSL certificate mismatch is detected, these vectors react quickly. In comparison to your case, imagine if malicious threat vectors digitally replaced my packet address with their own address so that my packet contents were hijacked to their new fake address. Now imagine that my XML packet contained customer names, addresses, credit card numbers, etc. The contents of my XML packet are now valuable assets to the malicious threat vectors. Remember, once data is released, it can never be unreleased. This is a serious process failure.
Initially in the process, all seemed well, delivery confirmation numbers were received and the process was deemed a success. That is precisely the reason why we guard against SSL certificate misconfigurations and precisely why my internal software system “...could not establish a secure channel...”; it detected something was awry and refused “delivery” as it should have. Now back to the data aggregator and my high-profile client.
My dilemma now was how to effectively approach the data aggregator. My new software company was a small start-up, and this new mobile app was an extremely important project for a high-profile international company. The data aggregator was also a gigantic company, with many years of experience and viewed by its peers and investors as a top leader in its industry. The stakes for me where as high as they get; I could not just saunter into the corporate offices and proclaim “hey, I discovered that your system is broken and it could compromise my client as well as all your own clients and even my client’s clients.” A misstep on my part could have been the end of my new company. Yet, the situation had to be remedied and all eyes were fixated on me and the proverbial breathing-down-my-neck was palpable and growing stronger. My solution was to work quietly and collaboratively with the data aggregator technicians in a teaming type environment to help "upgrade" their security posture. Together, we repaired the misconfigured certificates and I was able to invoke successful API requests. Essentially, by shifting our focus onto the technical issue, we became a single effective team from different companies with different skill-sets working together to solve a shared problem. In the end, we delivered our new app on schedule; it has been a great success for our customer, who by the way, is now a leader in their respective industry.
SUMMARY
One of the key lessons that I learned from this project: do not assume that just because organizations may be large, established, successful, highly regarded, that digital best practices are uniformly implemented organization-wide. Often with increasing size comes increasing process automation accompanied by over-reliance on established processes and a lack of process detail, self-examination, and process nuance. I even came up with a simple formula describing this project/process level phenomenon and how it can relate to the probability of your project success rates:
This case from my working life was about securing your assets before and during a transport process where data assets are moved and shared through multiple digital “highways and “curated” among multiple digital partners. Another related case is about securing the data assets residing inside your own systems and even during the process of transport. Imagine your process described above, and along the delivery route during the transport of your package, a threat vector intercepts your package, opens it, quickly copies all contents, reseals your package, returns your package to its designated place in your transporter and departs the scene, all unbeknownst to your transporter. In the digital space, this happens every second of every day. This is why we not only secure the transportation process of our digital assets, but also why we secure the assets themselves through cryptographic methods and tamper-proof seals. Read my blog Encrypting Key Assets if you want to discover another of my case histories of data-gone-awry.
Update: Encrypting Key Assets will be offline until further notice as I complete redactions to protect potential PII.
Leave a Comment