Skip navigation
All Places > Products > RSA NetWitness Platform > Blog > Author: RSA Incident Response Team

Introduction

FireEye recently released a large number of indicators to help security teams identify their set of stolen Red Team tools. The RSA IR team commends FireEye for releasing this information to the security community, to allow all of us to help better defend against attackers who might seek to abuse these tools.

While most security teams will be incorporating these indicators into their existing security detection infrastructure (https://community.rsa.com/community/products/netwitness/blog/2020/12/09/fireeye-breach-implementing-countermeasures-in-rsa-netwitness), the RSA IR team normally takes a different approach to identify threats, which is primarily focused on tool/attack behaviors instead of signatures.

The RSA IR team has long been a proponent of behavioral analysis, which in our experience help us continuously identify both known and unknown attackers. This analysis philosophy, coupled with an “Assume Breach” mindset, is at the core of Threat Hunting and Incident Response within our team. Therefore, in this blog we will look at the behavioral aspects of the tools related to the FireEye release of indicators, and provide some examples of how identifying suspicious behaviors can help identify attacker activity, without the need for specific signatures.

 

Credential Dumping

Adversaries attempt to dump credentials to obtain account login and credentials, normally in the form of a hash or a clear text password, from the operating system and software.

 

SafetyKatz

SafetyKatz is an open source tool, which is available on GitHub (https://github.com/GhostPack/SafetyKatz). It is an all inclusive LSASS password dumper. This tool will dump the memory of the LSASS process using the Windows API call, MiniDumpWriteDump, and then load a custom C# implementation of Mimikatz to pull information from the dump, subsequently deleting the LSASS dump file when it is finished.

 

Executing SafetyKatz on a host with NetWitness Endpoint, we can easily detect its usage via a number of indicators. From the screenshot below, we can see that NetWitness flags the file as malicious, based of RSA's file reputation lookup service. Furthermore, the agent generates metadata based of the behavior of the tool itself under the Behaviors of Compromise meta key, which is an unsigned application opening LSASS. Depending on how an attacker may use this tool, other generic behaviors, such as the location and name of the binary itself, can be part of the overall characteristics of this behavior. These behaviors should immediately stand out as suspicious and warrant further triage:

To configure file reputation lookup, please refer to the following article: Context Hub: Configure Live Connect as a Data Source.

                                                                                  

 

Executing the YARA rule from FireEye against the SafetyKatz binary, we can see that we indeed get a hit:

 

 

AndrewSpecial

This tool is similar to SafetyKatz in that it is open source (https://github.com/hoangprod/AndrewSpecial), and will create a dump file of the LSASS.exe process using the MiniDumpWriteDump Windows API call. It will not however, extract credentials from the dump created. From the screenshot below, you can see that the tool exhibits the same behaviour as SafetyKatz, in that it is an unsigned tool opening LSASS. This tool again, running from a unexpected directory should stand out to defenders and warrant further triage:   

 

Executing the YARA rule from FireEye against the AndrewSpecial binary, we can see that we indeed get a hit:

 

 

Closing Notes

The important takeaway from these two tools, is that simply relying on atomic indicators of compromise, such as signatures, which the attacker can easily avert, is not a scalable easily maintained solution to detection. Instead, relying on the behaviours of these tools and how they have to operate in order to achieve their goal, such as opening a handle to LSASS in order to dump the memory, we can easily detect the seldom used and unknown tools.

 

 

Discovery

Discovery consists of techniques an adversary may use to gain knowledge about the system and internal network. These techniques help adversaries observe the environment and orient themselves before deciding how to act.

 

SharpHound

In addition to NetWitness Endpoint flagging the tool's presence as malicious, we can still detect unwarranted tools being introduced into an environment through daily hunting. NetWitness Endpoint has two meta keys called dir.path.src and dir.path.dst that will group files running out of certain directories. We can then as defenders pivot into interesting locations and look for suspicious executables running from suspicious locations with ease:

 

 

For example, pivoting on dir.path.dst = 'uncommon' - we can look at all the files being executed out of uncommon directories. From the below we can see that cmd.exe was used to launch a suspect binary from C:\PerfLogs\ named, shp.exe:

 

This is a useful tactic to find malicious tools, as typically (but not always), attackers do not run their tools from the users Desktop.

 

Closing Notes

Sometimes it is not about having a signature to detect the tool and how it works, but rather to find the tool based on anomalous characteristics of its execution, such as it running from a suspect location. Discovery tools are constantly evolving and adapting to evade detection, meaning signatures for them can easily become obsolete.

 

Lateral Movement

Lateral Movement consists of techniques that adversaries use to enter and control remote systems on a network. Following through on their primary objective often requires exploring the network to find their target and subsequently gaining access to it.

 

Impacket

Part of the FireEye indicators included references to Impacket tools (https://github.com/SecureAuthCorp/impacket) such as smbexec. As part of our Profiling Attackers Series, two of these tools that aid in lateral movement have already been covered in previous RSA blogs, which we recommend you read:

 

 

However, it is worth mentioning a new feature in NetWitness that has been added since the release of those blogs. Namely, NetWitness has now introduced host-based information matched to the Packet data. If you have both NetWitness Packets and NetWitness Endpoint, as of 11.5.1, packet sessions will be enriched with the associated host based data, giving defenders the full picture from both the endpoint perspective as well as the network perspective:

 

To configure and learn more see the following article: https://community.rsa.com/docs/DOC-86987#Host

                                                                

 

Closing Notes

In order for an attacker to achieve their end goal, they are going to have to laterally move to other endpoints. While custom tools such as Impacket have been developed to make this task easier, as shown by the FireEye breach, the tools can be obfuscated to easily evade signatures. Whereas, as shown in the blog posts, relying on the behaviors of the tools we can ensure that we will always identify their usage.

 

Persistence

Persistence consists of techniques that adversaries use to keep access to systems across restarts, changed credentials, and other interruptions that could cut off their access. Techniques used for persistence include any access, action, or configuration changes that let them maintain their foothold on systems, such as replacing or hijacking legitimate code or adding startup code.

 

ZeroLogon

This is an exploit for CVE-2020-1472, a.k.a. Zerologon. This tool exploits a cryptographic vulnerability in Netlogon to achieve authentication bypass. Ultimately, this allows for an attacker to reset the machine account of a target Domain Controller, leading to Domain Admin compromise.

 

One of our content developers William Motley, updated the DCERPC Lua parser when this vulnerability was initially announced to detect this behavior on the network. This parser will generate the meta value, zerologon attempt, under the ioc meta key when the behavior is observed. Prior to the update of the DCERPC parser, the ZeroLogon CVE has previously been covered by Halim Abouzeid, and is a recommended read to show how these exploits can still be detected without signatures:

 

 

SharPersist

This is a custom tool developed by FireEye, and is freely available on GitHub (https://github.com/fireeye/SharPersist). This tool makes it incredibly quick and easy to setup persistence on an endpoint. We ran some of the mechanisms it offers on one of our victim hosts to see what meta values NetWitness creates.

 

One of the switches for the tool adds persistence via the registry using the \CurrentVersion\Run key. The following query can be used to identify any application persisting itself in this manner:

action = 'createregistryvalue' && ec.subject = 'runkey'

                        

 

 

Autoruns (i.e. persistent files) also have their own section for each endpoint. These can be reviewed in order to identify potentially malicious autoruns based on various characteristics of the file, such as signed/not signed, frequency in the network, location, etc. The screenshot below shows a malicious registry autorun:

 

 

The screenshot below shows a malicious service:

 

 

The screenshot below shows a malicious task:

 

 

You should also be collecting the Windows logs from your endpoints as well, as these can be used to help identify malicious autoruns. Querying events where reference.id = '7045' will show newly created services, these should be analysed to find potentially malicious services, from the below screenshot we can see that a suspect service was created referencing a binary in a suspect location:

 

Executing the YARA rules from FireEye against the SharPersist binary, we can see that we indeed get a hit:

 

Closing Notes

Again we have shown that regardless of the tools being used, the persistence mechanisms can all be detected based on the behavior of the service/task/autorun as well as the characteristics of the file behind the persistence mechanism.

 

 

Command and Control

Command and Control consists of techniques that adversaries may use to communicate with systems under their control within a victim network. Adversaries commonly attempt to mimic normal, expected traffic to avoid detection. There are many ways an adversary can establish command and control with various levels of stealth depending on the victim’s network structure and defenses.

 

DShell

We executed one of the tools identified by FireEye as, DShell (backdoor), to see what what indicators we could use to identify its usage within an environment. What we noticed was that the tool adds itself and its C2's as an exception in the firewall using netsh.exe; this gets identified by NetWitness Endpoint with the two meta values shown below:

 

 

It should be noted that in general, any C2 type file will exhibit additional behaviors once it is used to do something useful, such as upload/download files, enumerate processes/services/file system, etc. Here, we are simply executing it to observe its initial behavioral footprint.

 

Navigating to the events view we can see that the binary was located in C:\PerfLogs\ and named Program.exe. It spawned cmd.exe and passed the netsh argument to it:

 

 

This is one tactic for many C2's, njRAT for example will do the same, albeit with a slightly different command. For example, the njRAT execution on ANY.RUN exhibiting the same behavior can be found at the following link: https://app.any.run/tasks/7d09956b-6843-45f6-8bbf-5a5880999961/. This again shows that utilising the behaviour of the tool would allow defenders to identify its usage and others without having to rely on signatures.

 

Executing the YARA rule from FireEye against the DShell binary, we can see that we indeed get a hit:

 

 

Cobalt Strike / Meterpreter / DNS Tunnelling

A number of the signatures released by FireEye reference Cobalt Strike, Meterpreter and DNS tunnelling. While we have covered these tools in prior posts, some of the network detection discussed in them cannot be directly applied to the tools released by FireEye. This is because tools such as Cobalt Strike allow for malleable profiles that can easily be altered. With that being said, the hunting principles outlined in our Profiling Attackers Series whereby we hunt for these tools based on behaviours, shows that they can still be detected via proactive hunting:

 

 

 

Closing Notes

We have discussed hunting for C2's a number of times in other blog posts. Due to their flexibility and ability to dynamically change, it is seldom useful to employ signatures for their detection. Instead, identifying suspect characteristics associated with the communication can make them stand out even when they attempt to blend in:

 

 

 

Conclusion

The key takeaway from this post is while signatures are an easy way to detect known malicious tools/files, they are not ideal for today's network defense from the more sophisticated attacks. The intrusion into FireEye's network itself demonstrates this fact. The RSA IR team's philosophy is to assume a breach, and use daily hunting to identify abnormal behaviors in your network. We also always encourage our clients to invest in hunters who use our toolset to "patrol" the network both from the packet and endpoint perspectives. The sole reliance on signatures and alerts generated by them will only protect you from the known attacks. Signatures can be typically easily averted and become stale rather quickly. On the other hand, behaviors are more generic and fairly static, and will always allow you to detect what the signatures would have detected as well as malware not covered by signatures. 

1       Introduction

The efforts of people around the globe have suddenly forced many workers to stay at home. For a significant portion of these workers that also means working remotely either for the first time, or at least more often than their normal telecommuting schedule. As a result of this necessity, many organizations may be forced to implement new remote technologies or significantly expand their current capacities for remote users. This added capability can present a significant security risk if not implemented correctly. Furthermore, malicious actors never pass up the opportunity to capitalize on current affairs. The RSA Incident Response Team has years of experience responding to Targeted Attacks and Advanced Threat Actors while assisting our clients with improving their overall security posture. The members of our team are either working with our customers on-site or supporting them from home. Our team has frequently assisted clients remotely, providing us with extensive experience in operating a secure remote team. Given the increasing threat landscape,  we are sharing some essential tips and suggestions on how organizations can improve their security posture, as well as how their remote workforce can keep themselves secure by following some best practices.

2       Tips for Users that are Working from Home

During this time many workers will be shifting from the office life to a work from home life that is unfamiliar to most of them. Many workers will be experiencing this reality for the first time, while for others it will be the first time this has been an everyday occurrence. In addition to the recommendations provided on the RSA blog (https://www.rsa.com/en-us/blog/2020-03/cyber-resiliency-begins-at-home), the RSA IR team is providing some additional details and best practices that users can utilize to help keep themselves secure while working from home.  Additionally, the RSA IR team has published a blog with tips that organizations can use to help improve their security posture (RSA IR - Best Practices for Organizations (A Starting Point)).

2.1      Use Provided Corporate Hardware

Now that you have shifted to working from home you will still need to ensure all work-related tasks are completed using your organization's provided laptop, if available. Using the work laptop allows the user to still be covered by the organization's security protections. It also helps the user with accidental disclosure of sensitive work data if that information is being stored on a personally owned machine. Some organizations have a bring-your-own-device (BYOD) policy.  In those cases, RSA recommends following your companies normal policy for remote computing.

2.2      Passwords

The passwords used for all corporate logins should comply with your organization's password policy.  However, RSA recommends use of a Password Manager to increase your security. Password managers (such as LastPass, Password Safe, Dashlane, 1Password, Apple Keychain, among other reputable password managers) allow you to randomly generate a secure and unique password for each login and store them within a database. This allows you to comply with corporate security policies without having to remember each individual password (or worse, reusing the same password). The implication of reusing passwords is that if an account's password is compromised in one location, then all other instances that have the same password are also compromised.  We will also be discussing multi factor authentication next; suffice to say that we recommend that multi factor authentication be enabled for access to your password manager for increased security.

Several password managers can be found at the below link:

NOTE: Password managers will require users to remember a single master password in order to access the others. It should be complex and not easily guessable. We recommended that you adopt the concept of passphrases rather than passwords. A passphrase can be a sentence or a combination of words that have some meaning to you. For example, a passphrase could be: “I need to be on vacation now!” or “Correct Horse Battery Staple” (reference: xkcd: Password Strength ) One example of a passphrase generator is https://xkpasswd.net/

2.2.1    Default Passwords

Many devices require a username and password to log in for initial or further configuration.  Often these devices (such as home routers, WIFI access points, cable modems and other Internet devices) come equipped with default passwords (such as admin or password).  RSA recommends that all default passwords be changed to secure unique passwords, especially for devices that connect directly to the Internet.

2.3        Multi Factor Authentication (Also Known as Two Factor Authentication)

Using multi factor authentication (MFA) for all remote access, for systems hosting sensitive data, and for systems performing administrative functions within the organization is strongly recommended. Multi factor authentication, (which is an evolution of two factor authentication (2FA)), enhances security by requiring that a user present multiple pieces of information to authenticate themselves. Credentials typically fall into one of three categories: something you know (like a password or PIN), something you have (like a smart card or token), or something you are (like your fingerprint or Iris scan). Credentials must come from two different categories in order to be classified as multi-factor. Applications that are sensitive to the organization such as your password manager, customer databases, administrative tools, etc. should all have multi factor authentication enabled on them.

 

2.4      Follow Your Company's IT and Security Policies

Organizations have established IT and security policies to protect all employees as well as the organization itself.  Just because you are not in the office does not mean that you still should not follow these policies. Security policies surrounding the way you handle data, communications, installed applications, and things you can do on your laptop should all be followed. Company provided computers should not be treated the same as personal devices. This may include disallowing your family from using the company provided computer.

2.5      Allow Updates and Patching to Take Place.

If your organization has a patch management program in place users should allow these processes to function as they normally would when they are in the office. These update procedures will at times require a reboot so ensure your machine is online, connected to the corporate VPN (if available), and allow it to reboot when it asks. Do not skip patches as they are released by your organization's IT department so that your machine is not put at risk of being compromised. 

2.5.1    Update Personal Devices

In addition to allowing your corporate system to update, personal assets should be updated as well. It is easy to ignore security updates for your systems, devices, or applications by simply clicking “update later”. However, repeatedly delaying these updates can lead to serious vulnerability issues. Updates should be performed for your personal operating systems (such as Windows or MacOS for example),  web browsers (such as Chrome, Firefox, Internet Explorer or Edge), tablets (such as iPad, Kindle, or Android), smartphones (such as iPhone or Android), and any other device that requires updates.

2.6      Phishing / Scams / Link Safety

Phishing is an attempt to trick a user into believing that the email message is something that they need, want, or are interested in. Phishing scams typically revolve around current events of the world or common life events (such as shipping related to online orders, among others). The attackers know that the subject and content of the email will trigger either fear or intrigue on the recipient. This emotion will most likely cause the recipient to click a link within the email or open its attachment. The link will likely download a malicious application or present the user with a fake login page that attempts to harvest credentials for sites such as your bank, email, social media, online shopping, gaming or other important credentials.  This can result in the loss of access, fraud, or abuse of these accounts if the user proceeds to divulge this information.

If you are unfamiliar with what phishing looks like or some of the common tactics used for social engineering, we highly recommend taking the quiz linked below to improve your skills for spotting phishing attempts:

2.7      WIFI Security

RSA recommends encrypting home wireless networks with WIFI Protected Access (WPA). There are several versions (WPA, WPA2 & WPA3) with WPA3 being the current strongest. RSA does not recommend using Wired Equivalent Protocol (WEP) or unsecured wireless Internet.

2.8      Security Training

If your company offers security training, RSA recommends that you take (or retake if it has been a while) the offered training as you are potentially at a higher risk now that you are outside the office. We understand that these trainings are not always the most exciting learning experiences, however they do help to reinforce good security behavior and can act as a refresher for things you may already know. One good resource to start is the SANS Security Awareness Work-from-Home Kit (https://www.sans.org/security-awareness-training/sans-security-awareness-work-home-deployment-kit)

2.9      Improve Your Household's Internet Safety

All the devices on your local network are linked to each other in one way or another. It is therefore important to ensure that all members of your household are kept safe and do not infect you by proxy. A great way of ensuring your family's internet safety on the internet is by using Microsoft family:

2.10  Non-Security Tips for Working from Home

2.10.1  A Second Monitor

A second monitor can increase your productivity, improve workflow and generally provide an improved experience while working.  Many organizations are offering to let employees borrow work resources such as monitors for use during this period of working from home. Check if your company is providing something similar.

2.10.2  A Comfortable and Supportive Chair

Since you will no doubt be spending an increased amount of time in front of your computer working, you will also likely be spending an increased amount of time in your chair.  Having a comfortable and supportive chair can help with posture and ergonomics while working from home.

2.10.3  Consider a Standing Desk or Standing Desk Converter

For many people sitting all day is not ideal. To help combat this consider using a standing desk or a standing desk converter that allows a home user to decide if they want to sit or stand at will. If you’re not able to utilize a standing desk, then be sure to take breaks where you are able to stand up and stretch.

3      Conclusion

In these uncertain times, we hope that this advice will help organizations and users stay connected and stay secure. Watch out for more posts and advice from across the RSA organization, and let us know what you're doing in the comments below.

1       Introduction

The efforts of people around the globe have suddenly forced many workers to stay at home. For a significant portion of these workers that also means working remotely either for the first time, or at least more often than their normal telecommuting schedule. As a result of this necessity, many organizations may be forced to implement new remote technologies or significantly expand their current capacities for remote users. This added capability can present a significant security risk if not implemented correctly. Furthermore, malicious actors never pass up the opportunity to capitalize on current affairs. The RSA Incident Response Team has years of experience responding to Targeted Attacks and Advanced Threat Actors while assisting our clients with improving their overall security posture. The members of our team are either working with our customers on-site or supporting them from home. Our team has frequently assisted clients remotely, providing us with extensive experience in operating a secure remote team. Given the increasing threat landscape,  we are sharing some essential tips and suggestions on how organizations can improve their security posture, as well as how their remote workforce can keep themselves secure by following some best practices.

2       Tips for Organizations (A Starting Point)

While there are many steps organizations can take to better protect themselves and their users, the RSA IR team is sharing some essential tips and suggestions that we consider to be a good starting point. However, these are by no means a complete list.  Each organization should adjust the below recommendations according to the organization’s security posture, and risk profile and acceptance.

Many vendors are offering emergency capacity extensions or trials of their products in this time of unprecedented social change.  Check with your vendors to see if they have any such offers in place for technology that your organization does not already have implemented as it pertains to the recommendations listed below. For a strategic approach, take a look at the post from our colleagues on the Advanced Cyber Defense (ACD) team Work From Home - The Paradigm Shift in Cyber Defense.

2.1      What Organizations Can Do for Their Users

2.1.1    VPN

While it may be tempting and seem like an easy option to just make resources available online via services like RDP, this is generally not recommended. Threat actors love searching for vulnerable servers that are connected to the internet regardless of the port used. Search engines like Shodan are showing an increase in the number of servers exposing RDP directly to the internet (https://blog.shodan.io/trends-in-internet-exposure/ ). Open RDP servers are regularly used to infect organizations with Ransomware and other malware (Two weeks after Microsoft warned of Windows RDP worms, a million internet-facing boxes still vulnerable • The Register ). RSA strongly discourages organizations from exposing RDP services directly to the internet.

Organizations should utilize VPN (or VPN alternative) technologies for employee remote access. RSA IR has the following tips regarding VPN usage.

  • Ensure Licensing counts can support the increased number of remote workers.
  • Ensure that the VPN devices can handle the increased number of simultaneous connections and throughput.
  • For strong security, RSA recommends that the VPN be Always-On if possible. An Always-On VPN requires the system to be connected to the VPN whenever an authorized client is connected to the internet. If bandwidth, simultaneous connection count, or bring-your-own-device (BYOD) is of concern, this suggestion can be re-prioritized.
  • All traffic should be tunneled over the VPN (No Split Tunneling), thus enabling the same network visibility and controls as if users were in office. If bandwidth availability or bring-your-own-device (BYOD) is of concern to the organization, this recommendation can be re-prioritized.
  • Investigate VPN alternatives for certain users. Alternative remote access solutions also exist such as, Virtual Desktops Infrastructure (VDI), Cloud Infrastructure, Software as a Service (SaaS), and others.

2.1.2    Multi Factor Authentication (Also Known as Two Factor Authentication) For All Remote Access

All remote access (including VPN, VDI, Cloud, Office365, SaaS, etc.) should be required to utilize Multi Factor Authentication. Multi Factor Authentication, which is an evolution of Two Factor Authentication (2FA), enhances security by requiring that a user present multiple pieces of information for authentication. Credentials typically fall into one of three categories: something you know (like a password or PIN), something you have (like a smart card or token), or something you are (like your fingerprint). Credentials must come from two different categories in order to be classified as multi-factor. As mentioned, check with your vendors to see if they are offering any assistance with surge capacity or new solutions.

2.1.3    User Education

RSA generally recommends that all staff using computer resources within a company complete annual security training. However, during this time when more users are working remotely, RSA recommends that organizations hold a special organization-wide user education session on password safety, phishing attacks, IT security policies, as well as covering how to report issues to the IT and Security Teams. If you’re looking for a place to start, see our other blog post for tips for users that are working from home (RSA IR - Recommendations for Users Working from Home).

2.2      What Organizations Can Do for Themselves

2.2.1    Updates and Patching

RSA consistently finds out-of-date and out-of-support Operating Systems and software running in client environments. Older software often has public vulnerabilities and exploits that are freely available online and are often targeted by commodity malware as well as targeted attackers. RSA strongly recommends that any core software be aggressively updated on a regular basis, especially if a vulnerability for a particular application is publicly announced. Exploiting vulnerable software is one of the easiest ways for an attacker to find their way into the enterprise. At a minimum organizations should look to:

  • Update and Patch all external facing systems, servers and applications (including web applications or frameworks).
  • Update and Patch all Critical Systems internal or external.

2.2.2    Web Application Firewall

If not already deployed, RSA recommends implementing a Web Application Firewall (WAF) to better protect Internet facing web applications. A WAF solution can provide a reduction in the attack surface of web applications and in some cases, of the operating system itself. It is important to note that simply installing a WAF solution will not immediately secure all the web applications as all WAF solutions, regardless of vendor, need to be tuned for the specific applications and environments they are being used to protect.

If a WAF is already deployed, RSA recommends that organizations verify that it is in front of not just the business-critical web applications, but also all other external web-facing assets.

2.2.3    Leverage Freely Available Threat Intelligence Feeds

As notices have been released about increased attacker activity related to recent attacks and fraud (https://www.ic3.gov/media/2020/200320.aspx), many threat intelligence vendors are offering freely available intelligence of current threats and scams. Here are some of the companies offering related intelligence feeds for free, as well as providing some additional tools for analysts.

2.2.4    Endpoint Detection and Response (EDR)

Endpoint Detection and Response (EDR) is especially important to organizations that, for various reasons, are unable to enable an Always-On VPN. 

If your organization already has an Endpoint Detection and Response (EDR) solution, ensure that it is deployed to all remote users.  Since endpoints may not be sending all their traffic internally to allow for network visibility, EDR tools can help gain visibility of endpoints operating outside the internal network environment. Organizations need to ensure that data collected by the EDR tool can be transmitted to the central EDR server either continuously or while connected to the VPN. Organizations must also ensure that their licensing limits, as well as server capacity, support a potential increase in the number of endpoints.  Speak to your security vendors to see if they provide surge or Business Continuity increases during this time.

If your organization does not currently have an EDR tool, then consider deploying one.  EDR solutions now offer more than just detection and blacklisting of malware; but also, have built-in forensic capabilities such as acquiring remote system files, memory images, behavior analysis, and false positive management via whitelisting. This means that organizations can detect, respond and block malicious activity much quicker and without the need to create a full host forensic image for investigation. Additionally, once a Behavior of Compromise (BOC) is identified, the EDR solution should be able to detect where else in the enterprise that indicator has been observed. Speak to your trusted security vendors and see if they are offering any on a trial basis.

2.2.5    Remote Collaboration

If your organization does not already have a policy for remote collaboration tools (such as screen share), consider adopting one for remote users. At the very least, RSA suggests having a recommendation for users so that they do not seek out their own solutions.  Some examples include Zoom, WebEx, GoToMeeting, Microsoft Teams, as well as others.

3      Conclusion

In these uncertain times, we hope that this advice will help organizations and users stay connected and stay secure. Watch out for more posts and advice from across the RSA organization, and let us know what you're doing in the comments below.

Filter Blog

By date: By tag: