Skip navigation
All Places > RSA Labs > Blog > 2020 > April
2020
Matthew Tharp

Project Duma

Posted by Matthew Tharp Employee Apr 7, 2020

Today's security teams need help in analyzing network traffic to find threats. More and more attackers are using encrypted traffic. Previously defenders would rely on DNS lookups to identify the type of traffic that an encrypted session contained, but with domain fronting and DNS over HTTPS (DoH) defenders are losing their visibility. Project Duma is about helping analysts uncover threats in encrypted traffic by attempting to classify both normal and suspicious use of encrypted protocols.

The hypothesis behind Project Duma is that although encryption hides the actual data in route, it doesn't hide the application behavior. The application state machine can be profiled by looking at which endpoint sends how much data and how quickly. For example, if the connection is a long one with a large amount of data with a near constant throughput rate (like 1-3 Mbps) it is likely to be a streaming media connection. This technique could have many applications in profiling TLS traffic and unknown protocols. The project begins with a focus on identifying interactive SSH sessions and reverse shells.

 

The Secure Shell (SSH)

The Secure Shell protocol was developed in 1995 to provide a secure login connection for remote machines [2]. The protocol was intended to replace protocols like telnet and ftp that don't encrypt their traffic and send their authentication in the clear. The protocol became an IETF standard (RFC 4251) and is widely used for managing servers and transferring files.

Attackers want to use SSH because it provides them Command Line Interface (CLI) access to remote machines. If the attacker can further exploit the remote host to gain additional privileges or connect to additional hosts in the victim network they can use the encrypted network traffic to hide their exploits. Because SSH is so widely deployed for managing servers and remote connections attackers can abuse it while minimizing the amount of malware they have to install in the environment. Such a technique is called Living off the LAN and helps the attackers avoid detection.

Most security teams try to stop attackers by blocking inbound SSH traffic at their firewalls. But outbound SSH traffic is often allowed because developers want to SSH to their cloud instances or because the corporation needs to either send or receive files using the SFTP protocol. Astute security organizations will carefully limit what machines can use SSH to communicate to other machines outside their environment. However, with the increasing popularity of cloud services and SFTP to transfer files it is becoming difficult to police all those connections. This is especially true in the financial sector where we see an abundance of SFTP transfers and data sharing.

Project Duma looks beyond encryption to profile how the SSH protocol is being used. The protocol could be used to transfer files as in the case of SFTP. The protocol could also be used to remotely administer machines automatically through some scripts or other tools. It could be used interactively to control machines or it could be used as a reverse tunnel where although the SSH connection is initiated from inside the corporate network it is reaching out to an attacker who is actually sending commands to the machine that initiated the connection [3]. Detecting these reverse shells is the ultimate target of the project.

 

Status

Project Duma is currently in development and is showing some promising results. However, we are developing based on open sourced flows. These resources are typically published by universities for research and therefore don't accurately represent our customer base. Since the machine learning and data science approaches used in this project benefit from highly representative data we are looking for development partners that could contribute data sets for testing. If you or someone you know may be interested in partnering with us on this project please reach out and let us know by leaving your comments below.

 

[1] https://www.ponemon.org/local/upload/file/A10%20Report%20Final.pdf

[2] https://www.ssh.com/ssh/

[3] https://www.sans.edu/student-files/presentations/LVReverseShell.pdf

RSA Archer is a leading platform for integrated risk management, and a major component of the product suite is targeted towards mitigating third-party vendor risk. An Archer customer organization may have many vendors which supply products or services. Each of those suppliers carries with it a level of uncertainty with regard to reliability, security, and other factors that could impact the organization. Currently, Archer enables customers to use questionnaires, which are sent to internal employees and external vendors, to conduct due-diligence on such third parties and assess their level of risk.

 

Because customers may need to calculate the risk for hundreds to tens of thousands of third parties, they need to provide a way to complete these questionnaires and submit their documentation in an efficient manner. In addition, following the completion of each assessment, customers also need to collaborate with vendors to collect information for findings, contracts, insurance documents, performance metrics, and other risk management processes. Doing so can quickly become a complex and time-consuming task, which is made more difficult by the lack of a consistent means of sending and receiving the questionnaires and tracking the results. Depending on the vendor, everything from importing/exporting spreadsheets to answering questions over the phone has been attempted, with varying degrees of success.

 

The Archer Third-Party Portal is here to save the day! The portal was designed to address many of the shortcomings of the existing system and provides a simple, efficient, and centralized place to manage third-party questionnaires and their results. Some of the main features of the Third-Party Portal are:

 

User Segregation

  • External vendor users are completely segregated from the RSA Archer instance.
  • There is no need to worry about a misconfigured access role accidentally giving access to sensitive data within RSA Archer.

 

Maximum Availability

  • The vendor portal is hosted in the AWS cloud and managed by RSA.
  • No need for platform administration by the customer.

 

Archer Synchronization

  • Native synchronization is present between content in the Archer platform and the vendor portal.
  • Automatic publish process for assessments.
  • Synchronizing submitted portal content back into RSA Archer is automated and native to the service.

 

Automated User Provisioning

  • Vendor users are automatically provisioned based on the RSA Archer publish process.
  • Vendor users can invite colleagues to collaborate on assessments by providing only a name and email address.
  • The system automatically generates email invitations to the vendor user.

 

Vendor Portal Experience

  • Vendors have a centralized portal to log in and view assessments from all customers in a single dashboard.
  • An automated password reset capability reduces administrative overhead.
  • The portal UI provides an intuitive and consistent user experience.
  • Questions are displayed in an easy-to-answer format and the ability to add supporting documentation via attachments is provided.
  • Supports simultaneous editing by multiple users.

 

Please stay tuned to the RSA Labs blog for further updates. And let us know if you have any questions or feedback in the comments section below. Thanks for reading!

Brian Mullins

Mercury Rising

Posted by Brian Mullins Employee Apr 7, 2020

When the world underwent a major digital transformation in the mid-to-late 90s with the introduction of eCommerce, RSA was there. RSA pioneered the BSAFE cryptographic library, which Netscape then embedded into their browser to enable secure financial transactions over the web. Now as the world shifts again, this time towards decentralized infrastructure, RSA once again has a role to play. It’s in this context that we’d like to introduce the latest project out of RSA Labs: Project Mercury.

 

In 2018, RSA Labs investigated decentralized identity with Project Sif. Since then a lot of progress has been made in the field. Standards have emerged and development tools have become available. One area that has developed that looks particularly promising is around Verifiable Credentials. The idea behind verifiable credentials is simple but powerful. Verifiable credentials are cryptographically signed attestations that can be issued by anyone including governments, banks, or even a friend or family member. The key to their utility is that they can be instantly verified by anyone. The number of applications of this technology is limitless. Need a way to prove you’re licensed to operate a vehicle? The DMV can issue you a credential. Only want to interview candidates that can prove they have a college degree? Universities can issue credentials to their alumni. The list goes on and on.

 

The problem companies face in adopting verifiable credential technology is that much of the infrastructure must be custom built. It’s not simple to work with and requires specialized expertise. We’ve seen with Amazon’s AWS the value that companies can realize by building atop undifferentiated infrastructure. Similarly, there is a need to provide a set of tools and services that make verifiable credential technology easy for companies to build upon. The vision for Project Mercury is to build a suite of cloud-hosted services to enable companies to utilize verifiable credentials to improve their business. Improvement can come in the form of a streamlined user experience and/or reducing the cost and/or risk of doing business. Once this infrastructure is built companies will be free to innovate around the technology to achieve things not currently possible. RSA wants to be the catalyst that enables those transformations just as we enabled eCommerce 25 years ago.

 

To illustrate what’s possible consider the case of proving ownership of your bank account to your utility company to setup automatic bill pay. Today this is achieved by your utility company depositing a small amount of money into the account; a transaction which take several days to clear. Once you see the transaction appear in your bank account, you then must go back to your utility provider and enter the transaction amount, and then finally try to remember what it was you were doing in the first place. Instead consider this flow: The bank issues you a verifiable credential attesting to your ownership of your bank account. When your utility company requests your bank account information to setup automatic bill pay, you only need to present your credential. Upon showing your credential the utility provider can verify the information within seconds and you can be on your way. Another example where this technology may prove essential is in a post-Covid-19 world. Bill Gates and others have discussed the need for digital credentials that can provide assurances about vaccination or exposure. It’s possible that such credentials may even be required for traveling internationally. Verifiable credentials could fulfill such a need.

 

Things are just getting started with Project Mercury. Please stay tuned to the RSA Labs blog for the latest updates. Let us know if you have any questions or feedback through the comments below. Thanks!

As everyone grapples with lifestyle adjustments brought upon by a global pandemic it can be beneficial to stop and reflect on the unintended consequences of those adjustments.  One possibility worth considering is that COVID-19 may accelerate or drive increased adoption of IoT.

 

As we have gained more insight and understanding about SARS-CoV-2, the virus that causes COVID-19, we have learned just how long it can survive on surfaces, which may contribute to the high transmission rates being observed.  IoT can play a role in reducing this risk by creating touchless interactions with the world around us, reducing the number of shared surfaces we must touch.

 

Take a concrete example of a grocery store employee.  This employee may have to adjust the thermostat in the refrigerated section, something that a dozen other employees have touched in the last 24 hours.  If instead the thermostat was an IoT, connected device, it might automatically sense people in the building and adjust temperature without interaction.  If nothing else, the employee could interact with it remotely and not be forced to physically manipulate it.  This would safeguard employees by reducing interaction with a shared physical device that can act as a transmission vector.  There are countless other examples of where smarter, connected devices can lead to a better and hopefully safer environment.

 

In a 2019 white paper  (https://community.rsa.com/docs/DOC-107466) we cited Gartner’s forecasts of IoT usage for 2019 to be around 14.2 billion devices with projections reaching 25 billion by 2021. Governments were already actively developing “smart cities” where new and existing infrastructure was being outfitted with IoT devices for the purpose of increase operational efficiency. Likewise, consumer market for smart thermostats, cars, speakers, door-bells, and other devices is also on the rise as companies offer modernized solutions to existing products. In a post-COVID world, we can reasonably assume that demand and adoption of IoT will increase.

 

As companies rush to introduce new IoT solutions they need to take measures and safeguard against threats posed by those devices. This requires visibility and monitoring, as would exist in traditional IT environments, with analytics focused on detecting the threats that are common in IoT.  In particular, the IoT gateway, which serves as the last hop between the IoT device and the edge network leading back to the cloud, is a critical piece of infrastructure.  As such they also make attractive targets for attackers and need to be protected.

 

It is precisely this choke point where the RSA IoT Security Monitor is deployed to collect data, not just into the gateway, but by proxy into the connected IoT devices as well.  Meta data from these gateways is then fed back to a cloud service where machine learning and other behavioral analytics are performed; and visibility is provided to the customer.


Understanding that modern solutions require modern technologies, the RSA IoT Security Monitor solution is a cloud-native, microservice application provided on top of the AWS infrastructure enabling rapid scaling and high availability.  Insights can be viewed directly in a ReactJS UI (see Figure 1), or alerts can be consumed by any SIEM tool the customer may already be using; enabling a single pane of glass to see all incidents across an organization, whether they are typical IT assets or newer IoT assets.

 

Figure 1:

RSA IoT Security Monitor - Alerts

 

With this capability, RSA can continue to be a trusted partner that helps companies build durable solutions to security challenges.  For more information visit rism.rsalabs.com.