We receive a number of inquiries regarding AM network endpoints that offer Transport Layer Security (TLS, the replacement for SSL) with host (server) certificates signed by a self-signed root certificate. These network endpoints are used for internal communication between components within the product. They are often identified as “security vulnerabilities” because most network security scanners do not understand AM’s security model. Many of the network endpoints used by AM are a “closed system” and are only used by other AM components. These are not endpoints used by web browsers or by any other external system. While it makes sense to require that network endpoints used by web browsers not utilize host certificates with untrusted, self-signed root certificates, this does not apply to internally controlled, inter-component network connections. The use of these internally controlled certificates increases the security of the system by reducing the possibility of a rogue server or service being created.
During installation of a new primary instance, RSA Authentication Manager generates a new internal root certificate authority (CA) and creates new TLS host certificates for the new primary instance. It creates two sets of certificates, one for the web-based Security Console (and other consoles) and another set for use between components.
The certificates used for the web-based Security Console are created as a convenience to get the server up and running, and these can be replaced by generating a Certificate Signing Request (CSR), having the request signed by a certificate authority of the customer’s choice, and importing the signed certificate back into Authentication Manager. Once activated, these certificates replace the certificates generated at installation. Console certificates are generated for use with the Security Console and servers deployed in the Authentication Manager “Web Tier” such as the Self-Service Console, the Risk Based Authentication web interface, and the CT-KIP service endpoints. In each case, having a TLS certificate signed by a trusted certificate authority is an important element of system security, because end users are relying upon the web browsers built-in list of Trusted Root Certification Authorities to validate the authenticity of the server to which they are connecting (as shown in Figure 1).
Figure 1 - Internet Explorer Trusted CA Interface
The certificates used between the components are sometimes referred to as “plumbing” certificates. These certificates are used to secure communications between AM components and are never used with end user web-browsers. Each AM component verifies the authenticity of the remote server by making sure that server’s internal certificate is signed by the self-signed, special-purpose root CA certificate generated at the installation of the first primary instance. Since these connections are not used by web browsers, using self-signed certificates has no detrimental impact on the security of the system. To the contrary, this “closed system” increases the overall security by ensuring that AM servers will never trust another server presenting a server certificate signed by some external CA outside of the system’s control. The process of creating a new replica instance requires administrative credentials. It is only through this process that new internal server certificates are created for servers within a deployment. Without this control, any actor that can request a SSL server certificate signed by the external CA (often anyone within the same organization) would be able to potentially create a rogue AM server.
A self-signed certificate based public key infrastructure (PKI) provides security advantages:
There are at least two reasons why a self-signed certificate based PKI may have decreased overall risk. The first, also shared with private PKI systems, it that they avoid the problems of trusting third parties that may improperly sign certificates. [Secondly,] Self-signed certificate transactions usually present a far smaller attack surface, by eliminating both the complex certificate chain validation and CA revocation checks like CRL and OCSP.
As mentioned previously, the use of self-signed certificates has been reported in a number of issues and “requests-for-enhancement” reported to RSA Customer Support (AM-28955, AM-30231, and AM-30835, to name a few). These requests are generally associated with network ports 7002, 1813, and 7022, all of which are only used for internal communication and are not used in end user, web-browser interfaces.
Depending on the services selected, some customers may also see TLS network connections being offered by legacy protocols at ports 5550 and 5580. These are also only used internally between RSA authentication agents and the AM server and are not used for web-browser interfaces.
As you know, starting late Thursday and hitting mainstream over Mother’s Day there is a current outbreak of a ransomware threat known as “WannaCry” or “Wanna Decryptor”. Ransomware attacks like “WannaCry” are meant to be very visible in order to pressure the victim to pay the ransom. The scale of this attack, together with this specific ransomware family, is unique in that it has worm-like capabilities leveraging an exploit against vulnerable Microsoft Windows® operating systems. This exploit was recently made publicly available and appears to be associated with the “Shadowbrokers” release of nation state hacking tools. As of 5/15/2017 at 1pm ET, the associated income achieved is less than $50k the best we can estimate, less than 150 individuals or businesses impacted that were willing to pay.
While details are still emerging, RSA believes it follows a typical attack pattern where a malicious link is delivered through email as part of a phishing scam, whereby the malware installs itself. The malware can spread rapidly when an already infected computer is able to locate additional open and vulnerable computers with outbound internet connections. This malware can travel quickly through an internal network as a result of a core Windows networking function exploit. Microsoft issued a patch for this vulnerability under advisory (MS17-010).
The vulnerability exploited in this attack was made public in September, 2016. Microsoft released a patch in March, 2017. If an organization looks at their enterprise risk management with proper cyber hygiene, they may not have been vulnerable to this attack.
While mitigating attacks like this, which include host blocking, a robust backup strategy and comprehensive patch management, IT leaders should also be mindful that because of Microsoft’s patch support policy, any organization still running Windows XP, Windows 8 or Windows Server 2003 remain at high risk. Microsoft has issued specific guidance for this attack, which can be found here. This is not a new phenomenon and like in most major attacks, resistance is achieved with disciplined patching hygiene.
This latest wave of ransomware continues a trend with this popular attack method. Attackers are shifting away from stealing information for profit, rather taking advantage of the fact that data is critical to its victims for daily business operations.
While we continue to monitor and validate, at this time there appears to be no impact to the internal networks of any of the major Dell Technologies networks.
Individual alerts have been sent to clients using specific products. Because many clients leverage Microsoft OS and products as underlying components of RSA Products, there is a risk they could be impacted. That said, the actual product applications that RSA distributes are not impacted.
You may be asking how RSA can help. First, recognize that ransomware threats, by design, are noisy and are obvious to the infected victim … this is part of the criminal’s objective and business model. RSA NetWitness® Suite is designed to help identify and provide visibility into a ransomware attack – but as part of this attack method, the victim organization’s data is being encrypted by the malware. This is the same for any advanced threat detection and response technology platform.
From a risk perspective, RSA Archer is designed to help automate risk management, prioritizing activities to reduce risk (i.e. Vulnerability Risk Management) to mission-critical systems, and consistently and effectively manage an actual incident.
From an investigation and readiness standpoint, RSA can provide strong visibility and expertise, helping users to reconstruct, analyze, and understand the attack for current and future identification of ransomware behavioral indicators and operational performance optimization. Analysts within Security Operations Centers (SOC) can see suspicious activities such as lateral movement of infected systems, and/or attempts to infect workstations and other network and critical business assets to more readily determine the overall operational, business continuity, governance, regulatory and compliance impact of the attack to their business. Lastly, RSA can help security programs and IT operational functions see the last known good state of the workstation to understand when the incident first began in order to measure “dwell time”, determine SOC visibility and detection, gaps and remediation requirements as well as the ability to restore from known good backup. This can help limit data loss and reduce the prospect of paying ransom to the attackers.
In a large-scale attack like this, expertise and experience in readiness, response, resilience and business risk management is imperative. RSA can help organizations in their response and readiness efforts and programs. These attacks can be contained and preemptive efforts can be taken to block similar attacks from occurring in the future, minimizing the impact and scale of ransomware campaigns.
For a deeper dive on using RSA Netwitness to improve you visibility and make decisive steps to reduce the impact on your environment, see WannaCry from the RSA NetWitness Suite's Perspective and Blocking WannaCry with Netwitness Endpoint.
Here are some additional resources if you’d like to learn more about the attack.
New attacks are often followed by attack variants that use a similar infection vector with minor changes to bypass common defenses such as port and allowed path blocking. As such, four broad predictions:
While newsworthy and certainly impacting organizations, the underlying issue for WannaCry is patch hygiene. Understanding the IT investments needed to be able to upgrade applications tied to OS changes (i.e. config, patches, etc.) must be a focus for organizations to better improve vulnerability to patch to deployment. Understanding major newsworthy hacking event, can reveal defensive commonalities that can have broad, risk reducing impacts to the organization short and long term.
RSA’s Business-Driven Security solutions uniquely link business context with security incidents to help organizations manage risk and protect what matters most. The RSA Risk and Cybersecurity Practice, our expert professional services team, help organizations identify, assess, and close the gaps; and take command of their evolving security posture. Feel free to contact RSA for further detail or assistance.
Join more than 2,000 security, risk and compliance professionals at the premier Business-Driven Security event, RSA Charge 2017. This year’s event will be held Oct. 17-19 in Dallas at the Hilton Anatole Hotel.
This is your opportunity to network with RSA customers, partners, and industry experts while discovering how to implement a Business-Driven Security strategy in an increasingly uncertain high-risk world.
RSA University will also once again be offering condensed product-specific training courses beginning Monday, October 16 and on Tuesday, October 17, with information available soon on the RSA Charge microsite. Visit the microsite often to stay informed and maximize your experience at RSA Charge 2017.
Don’t miss this event - inspiring Keynotes, hands-on labs, strategic security sessions, technical deep-dives, and so much more; register today and save $300 with the Early Bird Discount through June 30.
See you in Dallas!
by Chris Wraight, featured on Speaking of Security Blog, May 9th
Your diverse, dynamic user base demands fast, convenient authentication and access—no matter where they are or what devices they are using. But you need authentication to be secure above all, with visibility across all applications and resources (cloud to ground),the assurance that your users are who they say they are and entitled to the access they demand.
Until now, you’ve had to choose between those two equally-urgent priorities: either sacrifice a measure of user convenience for security, or let convenience take precedence and put the organization at risk. Today, RSA announced new features and enhancements for RSA SecurID® Access that turn this no-win situation into a win for everyone, by extending identity assurance to the cloud and providing more flexibility and options to offer authentication your way.
Offer users a range of authenticators – mix and match to meet your needs
Whether you need mobile two-factor authentication (2FA), mobile multi-factor authentication (MFA with push notifications, OTP, SMS), biometrics (fingerprint, eyeprint), FIDO, hard or soft tokens, or a combination of some, or all of the above—RSA SecurID Access is the answer.
Make security seamless for your users and stronger for compliance
With our newly-enhanced risk-based analytics to validate logins in real time based on a variety of contextual factors, such as role, location, IP address, device type, login time and others, you’ll get the identity assurance not available from less advanced authentication solutions. The RSA approach to risk-aware authentication and identity assurance enhances both security and the user’s experience, because it’s only when the analytics indicate increased risk in real time that users are asked to step-up authentication.
Speed access to more of the applications users want
RSA SecurID Access delivers a frictionless user experience, with flexible authentication methods that quickly connect users with applications, including the SaaS apps they depend on most. It enforces access policies for more than 500 apps right out of the box, giving users ready access to the apps they rely on, from whatever devices they’re using. Mobile authentication is also part of the experience, speeding onboarding so users can quickly and easily access everything they need to be productive.
Protect access for all your resources – from the ground to the cloud – it’s your choice
You can use RSA SecurID Access to manage access to your on-premises, web-based and SaaS applications, and you can deploy it on-premises or as a service. Hybrid deployment is also an option if you’re not ready to make the total transition from an on-premises deployment to authentication-as-a-service.
Do more with what you already have
If you’re already using a version of RSA SecurID Access, the latest multi-factor authentication and risk-based analytics capabilities mean you’ll get more than ever from that investment. If you’re using RSA Authentication Manager, you’ll find it easy to migrate users to mobile multi-factor authentication with one application. And you’ll have the convenience of a single authentication provider meeting all your needs and a single solution for access to on-premises and cloud applications on all major mobile platforms. You can also keep your existing SSO platform in place, since RSA SecurID Access includes API support for third-party SSO providers. Or, you can just use the SSO that comes with RSA SecurID Access Enterprise and Premium Editions.
SecurID Access offers convenient options for authentication like push, biometrics, etc. Many of these are smart phone centric so, depending on how your system is deployed, your users may be required to have their mobile phone to authenticate. Occasionally, a user will forget their phone so we need to have a way to handle these emergency access scenarios. Here are the options in SecurID Access.
1. Do you have an Authentication Manager server attached to the SecurID cloud service? If so, make sure it is upgraded to release 8.2 SP1. As long as you are on that release or greater, your users using the SecurID Authenticate App can get emergency access just like your SecurID token users. Helpdesk admin can give the user a tokencode with a specific time limit (24 hours, for example) to get them through until they get back to their phone. Full details on this is available here Provide an Offline Emergency Access Tokencode.
2. If you don't have the Authentication Manager server connected to the cloud service, policies can be used for these users. Policy exceptions can be made to allow a specific user access with password only. The key here is to make sure that you have a process in place to revisit the policy the next day to reset it to normal after the emergency access period.