As the federal government makes a massive move to the money-saving cloud, IT pros must adhere to the defined security requirements for the federal use of cloud services as they move a selection of key functions.
Matthew McKenna is chief commercial officer at SSH Communications Security
When it comes to IT, federal agencies are tasked with ensuring cost efficiency as well as top-notch security. As the federal government makes a massive move to the money-saving cloud, IT pros must adhere to the defined security requirements for the federal use of cloud services as they migrate a selection of key functions.
The Federal Risk and Authorization Management Program provides guidance regarding the security objectives that must be met to achieve compliance. The challenge in effectively implementing any security framework, including FedRAMP, is making sure there are no major gaps between the security intent of the framework and the technical and administrative controls actually used in a given implementation. One of the most common areas of disconnect between security intent and implementation is in the realm of privileged, encrypted access.
Issues With Identity and Access Management
A common method used to restrict access on mobile networks, the Internet and the cloud is the Secure Shell protocol. In Secure Shell networks, key-based authentication is used to gain access to critical information. Keys are easy to create and are, at the most basic level, simple text files that can be easily uploaded to the appropriate system. Associated with each key is an identity: either a person or machine that grants access to information assets and performs specific tasks, such as file transfer, database update and log management.
In the case of Secure Shell keys, those text files provide access to some of the most critical information within an organization. In cloud environments, these authorizations can extend into the hypervisor and orchestration layer of the infrastructure.
This is a well-structured system – until human nature is factored in. System administrators and application developers will often deploy keys to readily gain access to systems they are working on. These keys grant a fairly high level of privilege and are often used across multiple systems, creating a one-to-many relationship.
In many cases, employees or contractors who are terminated—or even simply reassigned to other tasks that no longer require the same access—continue to carry access via Secure Shell keys; the assumption is that terminating the account is enough.
Unfortunately, this is not the case when Secure Shell keys are involved; the keys must also be removed or the access remains in place.
In addition, these keys can be used to subvert privileged access management systems. Many PAM systems use a gateway or jump host that administrators log into to gain access to network assets. PAM solutions connect with user directories to assign privilege, monitor user actions and record which actions have taken place.
Sounds like an airtight way to monitor administrators, right? It is, until one realizes how easy it is for an administrator to log into the gateway, deploy a key and then log in using key authentication, a clever way to work around any PAM safeguards in place.
Migrating to the cloud has its share of security concerns, but identity and access management take center stage. Essentially, in the past when federal agencies had their own private data centers in the traditional model, they could employ a perimeter-based security approach in which the outside world was kept separate from the data centers. There were walls between the two and the data center was considered a trusted environment.
With the move to cloud, the perimeter breaks down in many respects, so the notion of trusted and untrusted zones has disintegrated. Federal IT admins need to provide access controls and monitoring throughout the path of data processes. The security requirements are more pervasive because the entire environment is not necessarily considered trusted; all processes must be continuously monitored and controlled.
In addition to problems with access control, there are difficulties with PAM as well.
Conventional PAM solutions, which use gateways and focus on interactive users only, are designed to monitor administrator activities. Unfortunately, as mentioned above, they end up being fairly easy to work around.
Additionally, encryption blinds attackers the same way it blinds security operations and forensics teams. For this reason encrypted traffic is rarely monitored and is allowed to flow freely in and out of the network environment to allow these blind spots to exist. This creates obvious risks and negates security intelligence capabilities to a large degree.
How do most IT administrators handle encrypted traffic at the perimeter? Most of them simply let it flow on by. An online search for “SSH firewall” yields is a number of highly instructive articles on how to use Secure Shell to bypass corporate firewalls. This is actually a fairly common and clever workaround policy that unfortunately creates a huge security risk. To eliminate this risk, the organization must decrypt and inspect the traffic.
Monitoring Encrypted Channels
Decrypting Secure Shell traffic can be tricky, as doing so would usually interfere with the network. To avoid this interference, federal IT admins would need to use an inline proxy with access to the private keys—essentially, a friendly man-in-the-middle. When this method is successfully deployed, 100 percent of encrypted traffic for both interactive users and M2M identities can be monitored.
Also, because this is done at the network level, it is not subject to attack by host-based malware. With this method, federal agencies can proactively detect suspicious or out-of-policy traffic and eliminate network traffic blind spots. This is called encrypted channel monitoring and represents the next generation in the evolution of PAM.
Access management that is context-aware—in other words, knowing the “who, what, where and why” of every transaction so its bona fides can be validated—is a topic FedRAMP discusses. It is particularly necessary for encrypted communications. For federal IT admins, FedRAMP means having a level of visibility into these communications that wasn’t required before and is now central to the security needs of cloud services.
Federal agencies can go beyond the gateway approach to PAM by using encrypted channel monitoring. This will enable them to monitor and control encrypted sessions based on policy and context.
For example, policy controls can be enforced to forbid file transfers from certain critical systems. With the more advanced solutions, an agency can even block subchannels from running inside the encrypted tunnel, providing an effective defense against one of the preferred methods of data exfiltration.
To safely execute a cloud data migration process, federal IT administrators should keep in mind not only the access controls in context needed for privileged users but also for privileged processes, because there is a higher degree of automation in a cloud services environment. Automated processes are now taking over more and more privileged functions, creating a need to monitor those as well.
It’s an understatement to say a lot is riding on the security level of federal data migration to the cloud. It’s a complex and relatively new process, so important steps can be overlooked. In addition, busy IT admins often undermine the safety of their own networks with quick but risky workarounds.
What’s more, conventional PAM is no longer sufficient, because of the need to monitor encrypted channels. Federal IT admins need to make sure both their encrypted networks and those of their cloud service providers are proactively and continuously monitoring for security events. With such a holistic strategy in place, IT staff can feel confident they are following best practices for a secure cloud migration.