As a PKI and Identity provider we are held to a higher standard when it comes to Identity Security. In this blog we will walk you through how we follow Azure security best practices to secure our cloud only infrastructure.
While the image above might seem impressive and it is something all organizations should try to achieve, it is not enough to protect an organization in today’s zero-trust world. To do this we must focus on decreasing surface area and having good visibility into your organization. Here are the key focus areas we have focused on to secure our infrastructure.
While Azure provides many identity security features such as conditional access and risky logins, no account is truly secure until there is absolutely no password to steal. To protect against identity theft we have gone fully passwordless for our user accounts as well as our machine identities, while this might seem like a very hard to achieve north star, if the right tools are implemented it will not only make your organization more secure but will also improve overall productivity.
Let us first talk about passwordless user authentication, to achieve this you can either use SmartCard authentication or FIDO2, we use both. The reason behind this is that while FIDO2 has been the industry standard for many years, there are still many cases (even in Azure AD) that it is not accepted as an authentication method, we found that FIDO2 + Azure CBA cover all the scenarios we use at Keytos. We can seamlessly use these two authentication methods by having our users self-onboard to their passwordless identity using EZSmartCard
Usually when you think of passwords you think of user identities, however, passwords are everywhere, and one of the most dangerous places is machine passwords, that give them access to: machines, Azure AD, databases, and more. To remove all these passwords, we mostly leveraged Azure Managed Service Identities (MSI) these identities are fully passwordless identities that are managed by Microsoft, making it very easy to authenticate with other microsoft services.
For scenarios where MSIs are not supported such as cross tenant authentication, or for when our applications are hosted outside of Azure such as in customer’s on-premises servers, we use Azure Service Principals with certificate-based authentication. Unlike with MSIs, or regular certificate-based authentication, certificate-based authentication for service principals requires to register each new certificate in Azure before it can be used. We prevent certificate expiration related outages, by leveraging EZCA’s automatic certificate rotation for Azure AD Applications.
At Keytos we run critical services for many large organizations, this requires us to step up our game to the highest level of security, while our industry leading passwordless strategy dramatically reduces our surface area, we are going above and beyond by following Microsoft’s identity best practices and created our isolated production tenant that has no connection or trust to our corporate tenant. That means that if a corporate account gets compromised, the attacker would not have access to our production resources. This isolation also allows us to have stricter requirements for such as: having smart conditional access policies that grant access based on risk factors such as: smart login scores and device health.
While identity isolation is a great step on securing your resources, this only protects from identity theft. But we are seeing hackers get smarter and attack organizations with malware attacks that steal your credentials or access resources using your computer. To mitigate this risk, we have implemented a modern version of the Microsoft PAW model. Instead of leveraging legacy on-premises technology such as domain controllers, we use Azure Intune to manage the devices and Azure conditional access to attest device health before each login.
One of the main goals of our security posture is to secure our environment without having an impact to our most precious resource, engineering efficiency. We do this by giving our engineers a powerful workstation where they can do their engineering work and corporate tasks such as email, presentations, etc. In addition to a small lightweight laptop that can only be used to access production or RDP to their workstation.
Although we are very confident on our secure identity and device story, we also believe humans should not access production unless it is necessary. This does not only improve security, but by making access to production harder, it also promotes good engineering practices for deployment automation and self-healing features that improve our reliability and productivity. To enforce this, we have implemented no standing access to production, if an engineer needs to access any production resources, they must request access to the resources through Microsoft PIM or through EZSSH for our Linux endpoints.
With the reduction of production access and identity strengthening, we have seen hackers move left on the software supply chain attacks and target GitHub. To prevent these attacks and protect our infrastructure, we extend our already secure AAD identity to GitHub for SSO. While this is a great first step to protect our code, it only protects against actions created in the GitHub site, but as we all know, most privileged git activities happen over SSH. To protect our SSH access to GitHub, we use EZGit, the first GitHub SSH Certificate Authority this gives our engineers just in time access to the code, ensuring that every time they push or pull code they are doing it from a computer that meets our conditional access policies in Azure AD.
However, DevOps security does not stop when you commit the code, supply chain attacks are on the rise, including compromising open source build packages used by GitHub actions, to protect our artifacts from these types of attacks, we use Step Security’s harden-runner to monitor and block these attacks.
Following Microsoft’s assume breach mentality, we cannot just rely on our security measures to protect our infrastructure, we also must monitor it and detect any anomalies. Other than using the tools provided by Azure such as Sentinel and Azure Defender for Cloud, we wanted to take our security to the next level and monitor more events, that is why we created CloudWatcher a free open-source monitoring solution that will monitor any slight changes in our Azure environment and alert the on call engineer if any changes are detected. As a security company we also follow Google’s recommendation of monitoring certificate transparency logs with EZMonitor, not only protecting us for someone creating SSL certificates for man-in-the-middle attacks, but also other attacks such as the Azure domain takeover attack we discovered last year.
These strict controls have enabled us to meet and exceed compliance requirements for compliance standards respected across the industry, such as SOC 2 type 2, and PCI level 4. If you have any questions about how we secure our infrastructure or how we can help you secure yours, schedule a call with our security experts and start your zero-trust journey with Keytos.