Formed in 2009, the Archive Team (not to be confused with the archive.org Archive-It Team) is a rogue archivist collective dedicated to saving copies of rapidly dying or deleted websites for the sake of history and digital heritage. The group is 100% composed of volunteers and interested parties, and has expanded into a large amount of related projects for saving online and digital history.
There are major cyberattacks and data breaches weekly, if not daily. Each incident is unique in some way, but one element common to almost all successful attacks is trust. Whether it’s a disgruntled employee conducting an insider attack, an attacker infiltrating the network using stolen credentials or an exploit that leverages a third-party vendor or supplier, what makes the attack possible and allows attackers to fly under the radar is the fact that the credentials and activity appear to be legitimate. A zero trust security approach could solve that.
In DevOps environments, where new application architectures such as microservices and containers make things much more dynamic and rapidly changing, security can be especially difficult. Automation, virtualization and new tools combine to increase the potential attack surface exponentially. And, granting and removing access for containers or virtual machines that appear and disappear by the hundreds can be a Herculean task—traditional permissions management and access control solutions just can’t keep up.
“DevOps creates a challenge for many organizations because they need to maintain agility while also recognizing that security is an increasing concern in broadly distributed networks,” said Bill Mann, chief product officer at Centrify. “Prioritizing functional requirements over security while building applications leaves organizations exposed to significant risk.”
Centrify, however, is up for the challenge of bringing zero trust security to DevOps environments. The company claims to simplify integration of security into DevOps applications development pipelines without restricting development velocity.
Centrify starts with the premise that users, applications and endpoints are not trustworthy by default. Everything must be verified at every point of access to ensure that security of the development pipeline is not compromised in any way.
Its DevOps-focused portfolio includes products that help developer, security and operations teams manage access to complex development environments, enhance application security and provide auditable logs of privileged activity. Centrify provides centralized management of user access rights and privileges to Linux and Docker hosts, including hosts running CoreOS Container Linux. I am especially intrigued by its ability to implement multi-factor authentication (MFA) and temporary privilege elevation to gain access to individual containers independent of the container hosts.
Centrify also announced that it can now be used to authenticate to HashiCorp Vault, one of the most popular tools for securely strong and accessing secrets. Centrify provides centralized access management for the Vault, as well as protects against malware attacks by eliminating the need for locally stored access credentials.
On the application security side, Centrify focuses on securing privileged service and system accounts and enabling secure communication between applications, containers and microservices. Centrify leverages Kerberos, SAML or OAuth to enable services authenticate to each other.
The basic premise of Centrify is that “trust but verify” sounds good in theory, but in reality “never trust, always verify” is a much better strategy for security. Rather than hoping you can find the needle in the haystack and identify the one bad actor, it makes more sense to assume the bad guys already exist both inside and outside your network and simply remove trust from the equation.
The approach certainly seems to have some merit. It’s sort of like applying a whitelist instead of a blacklist to filter email or applications. Rather than assuming everything is good and trying to find the bad ones, just assume everything is bad and only let through the ones you choose. In this case, however, you don’t even have the whitelist. You’re literally verifying the user and device and applying policy to determine the level of access and privilege each time.
