I was visiting customers and prospects in South East Asia (SEA) recently where I visited several local and global banks. While I was speaking with them about machine identity protection, I got some interesting insights on things that are troubling them. The issues that they were facing were not necessarily consistent with what we see elsewhere. In fact, they were rather surprising to me.
In other regions, our customers come to us mainly because they have experienced severe certificate outages. They want to know how we can help them automate the certificate life cycle, and make it better and easier for them to protect and manage their machine identities. As I discovered, it's a completely different scenario in the SEA region. They do have outages, but they have sort of come to expect them as a matter course. So, they just deal with them when they occur.
Banks here, like others around the world, are indeed concerned about implementing end-to-end encryption. It's pretty much a given for the financial sector. So, banks will encrypt everything from the starting point to the storage point of the data. However, the concept of machine-to-machine (M2M) encryption is pretty new to sectors outside of financial, banking and insurance. It's probably two years old in some countries, resulting mainly from the enactment of the Privacy Data Protection Act (PDPA). So, when the auditors started paying attention, so did the banks.
So, to avoid audit findings, these banks began implementing M2M encryption for data at rest, data in motion, and so on and so forth. In practice, what I saw was that these banks were relying heavily on self-signed certificates to meet compliance mandates. But, while they were attempting to ward off audit findings, they were still struggling a lot with self-signed certificates internally. With external certificates, they were fine. But their internal certificates were completely mismanaged. This issue did not miss the attention of the auditors.
Apparently, there has been an uptake in audit comments being made by internal and external auditors, indicating that banks need to have management over their self-signed certificates. One way of doing it is by creating an internal PKI. That may seem like a no-brainer to you and me. But, for a lot of these banks, even some of the top 10 banks regionally, they had not yet invested in an internal PKI. As a result, they were unable to manage their PKI infrastructure. Nor could they enforce security policies for their internal certificates. That is why they had begun using self-signed certificates in the first place.
Because their M2M encryption was motivated by compliance rather than security, there were a lot of self-signed certificates being used. These self-signed certificates were not easy to keep track of and that (as we know) can become a rather complex problem down the road.
When using self-signed certificates, one of the biggest issues that the banks struggle with is lack of ownership. They know that self-signed certificates are managed by individual teams. But no one group has global oversight. This begs the question, “Should the banks allow the infrastructure teams to continue using self-signed certificates?” The answer is “No, that's not a good long-term strategy.” Compliance and audit teams will never allow it. So that leaves the banks in a bit of a lurch. Moving from self-signed to managed certificates results is an arduous task and can create a rather large operations overhead. First, the bank has to create a new unit. So, they must recruit and hire someone with in-depth experience in managing this new infrastructure. This person must be qualified to take on responsibility for the entire inventory of internal certificates. That is not an easy person to find.
Once the transition begins, the banks suddenly realizes that the process of issuing and deploying certificates is completely different. It’s a much longer process. And one of the reasons they have been using self-signed certificates is to avoid the steps that an internal PKI requires. In the past, they just ran a command and it worked. But with properly managed PKI, they will need to have a defined series of workflow approvals, they’ll need to generate a proper certificate signing request (CSR), submit the CSR, receive the certificate and then finally start installing it. This does not even include a proper validation process. As you can easily guess, it’s extremely time consuming to manage this process manually.
So now banks throughout southeast Asia have begun to evolve their M2M encryption strategies to favor internal PKI (with just a little nudge from the auditors.) What they just are beginning to realize as they implement these internal PKIs is the power of automation to simplify (and strengthen) this new process. With a powerful platform that automates machine identity protection, these banks can regain much of the simplicity of self-signed certificates. But they can also manage them more effectively and hold a tighter rein on policy enforcement. But, more importantly, they’ll meet the original goal of compliance, while benefiting from the side effect of lowering the risk of outages or security incidents.
What can automation do for your internal PKI?