Skip navigation
All Places > Products > RSA NetWitness Platform > Blog > Author: Choon Hian Koh


By now, you may have already started to work from home instead of your usual workplace, like many of your co-workers and peers. As the situation continues to evolve, there is a rapidly increasing trend for organisations to shift their employees from office to work from home. In addition to the recommendations provided in the following RSA blogs: Cyber Resiliency Begins at Home, RSA IR - Best Practices for Organizations (A Starting Point), and RSA IR - Recommendations for Users Working from Home, in this post, we will be going into further details to examine the potential challenges that cybersecurity professionals are contending with as organizations around the globe start to transit more employees from offices to work-from-home arrangements and conducting meetings through virtual means; this transformation in how we work and conduct our businesses will inevitably have an impact on our threat environment. We will discuss in the subsequent paragraphs on what is the paradigm shift in our threat landscape and what should we do to continue to stay effective in safeguarding our assets from the emerging cyber threats.



There are 2 key problems that we see here which we will break it down in the following paragraphs:


Problem #1

The cyber defense architecture for many of the organizations today are designed based on the assumption that most of the daily BAU activities are performed on-premise. With the sudden need to allow a good number of employees to work-from-home, it means that many of the activities would now have to be performed remotely. The challenges in provisioning or scaling of the necessary IT infrastructure to support these sudden changes aside, this also gives rise to a shift in the threat landscape, where the existing cyber defense measures that have been working in the past, may no longer be effective now.


Problem #2

There is an increasing trend that attackers are preying on the psychology of human beings by coming up with new attacks related to the latest trending news topic or specifically targeting work-from-home employees through the remote meeting applications that they use, for example:

  • Phishing Emails and Malware Attachments disguised as legitimate meeting invites and installers from popular remote meeting applications.
  • Malicious mobile applications promising to be the most up-to-date outlet for tracking the latest breaking news and developments.
  • Domain names that are similar to popular remote meeting platforms.


Combining both the above-mentioned problems and coupled with the tendency that as humans we naturally feel more comfortable in our home setting as compared to offices, there is an increased likelihood where some of us may be letting our guards down when it comes to spotting Phishing Emails, Malicious attachments and applications, as well as malicious websites that come knocking on our door at the least expected timing. All these can lead to an exponential increase in the level of cybersecurity risks faced by your organization and when there is a sudden surge in the number of cybersecurity breaches, does your organization have the capacity to handle them?   



Here, we look at what you can possibly explore as part of the Cybersecurity Team in your organization from the perspectives of People, Process and Technology to address the above mentioned issues.



Virtual Cyber Awareness Briefings. With increasingly more employees working from home, you can no longer conduct the usual quarterly cyber awareness briefings in traditional classroom settings. Instead of halting these briefings, why not take them virtual in the form of webinars for all employees who are working remotely. There are many platforms which can allow you to do so, such as WebEx, Zoom, Adobe Connect etc. You can also record the sessions and make them available offline for employees who are not able to join the live sessions.


EDMs. Apart from virtual awareness briefings, you should also look to increase the frequency of Electronic Direct Mails (EDMs) to remind the employees on the necessary cyber hygiene that they should continue to practice even when working from home.


Reward-based Quizzes. Besides briefings and EDMs, you can also take one step further to implement regular reward-based quizzes related to different cyber hygiene topics, in order to encourage and engage your employees in an interactive manner.  


Phishing Tests. Lastly, to assess if the above initiatives are effective, the best way is to test it out by implementing a Phishing Campaign on your internal employees. This could include regular phishing tests to your employees to assess their alertness in spotting such threats. You should also look to send out such emails in batches and in a random manner across different departments and regions such that the employees are not able to “cheat” the test by sharing information with their peers on such ongoing tests.

For the above initiatives, you could potentially include phishing topics that are related to the latest trending news or emails disguised as coming from legitimate remote meeting applications (e.g. meeting invites) in order to mimic the latest threats that the organization is facing.



There are a couple of key processes which would require review and revision, to ensure that they are relevant to the work-from-home model. For example: 


Access Control. With the increasing number of employees working from home, you need to review the existing access control related processes, such as the requirements for an employee to qualify for remote access. For example, your Access Control List (ACL) for remote access could be previously role-based, but this may no longer applies if you are in the situation where practically most of the employees across different roles may require remote access. With this sudden growth of remote access employees, are the existing access control provisioning and review processes still practical and relevant? Of course, there are many other issues to consider in this area, which will be too long to be discussed in this post.    


Incident Reporting. With the work-from-home model, you need to ensure that all employees working remotely are familiar with the incident reporting mechanisms in the event of any suspicious happenings. For example, they need to know what is the reporting hotline and email address which they can reach out to on a 24/7 basis, as well as other automated reporting mechanisms such as having a tool to report on phishing emails in their outlook application.


Cybersecurity Champions. Apart from the regular Incident Reporting mechanisms, you should also consider appointing representatives across different departments or teams as “Cybersecurity Champions”, who are basically regular employees (i.e. not part of the Cybersecurity Team) but are more proficient in the area of the relevant security processes in the organization. This initiative will allow employees to reach out to someone whom they are familiar with if they are unsure of any suspicious happenings or if they would like to have a quick refresher on what are the best practices in cyber hygiene.  


Incident Response (IR). Are your existing IR processes robust enough and tailored to include the remote working model practiced by most of your employees right now? You should look to review your existing processes covering the following phases and ensure that they remain relevant to the latest Business and Operating models of your organization:

  • Triage
  • Investigation
  • Containment
  • Eradication
  • Remediation
  • After Action Review



Access Control. In terms of access control provisioning for remote working, you should consider what is the best approach to implement multi-factor authentication in a manner where you can scale up/ down the infrastructure quickly in a cost-effective manner. The options could include the following, depending on your existing set-up, requirements and budget:

  • Hardware token
  • Software token
  • SMS/ Email OTP


For operations on critical servers that need to be performed remotely, there may be a need to differentiate them from the regular 2FA that is provisioned for normal remote access, by having a further step-up in the authentication process.


Monitoring and Detection. With the shift to the remote working model, there is a need to put more focus on the SIEM Use Cases related to VPN and remote access so that you can pick up such threats early. These are some examples of the Use Cases that may be relevant to the remote working model:

  • Detecting VPN access from suspicious locations
  • Simultaneous VPN Geo login from a single user
  • Suspicious remote logon hours from critical admin accounts
  • Remote admin session reconnected from a different workstation
  • Mass phishing attempts targeting your organization
  • and many more..


Endpoint. There are many different layers of endpoint controls which become especially important for the work-from-home model, such as the following:

  • Hard Disk Encryption for all PCs, so that the corporate data remains protected even if they are misplaced
  • Mobile Device Management which allows IT Department to manage the corporate information stored in mobile devices and allow the corporate information to be securely removed remotely if they are misplaced.
  • Endpoint Detection and Response to detect advanced threats in your endpoint devices, which may not have been picked up by traditional Anti-Malware solutions.
  • Data Labelling Enforcement and Data Loss Prevention (DLP) – Enforce data labeling for all documents and emails created or modified, and implement DLP to detect or prevent unauthorized movement of sensitive data.
  • Application Whitelisting as a second layer of defense against unauthorized installation of malicious applications masqueraded as genuine ones into the corporate PC.  


Network and Servers. To ensure that you are not opening up the attack surface of your network and assets given the increased number of remote connections, you should consider the following:

  • VPN provisioning for all remote connections.
  • Network Access Control to disallow remote connections from PCs to the corporate network if the Anti-Virus definitions or patching status of the PCs are not up-to-date.
  • Jump Server. Consider placing a Jump Server in front of critical servers to serve as an added layer of defense. This is especially important if the servers are critical but need to be accessed remotely.


Email. For corporate emailing, you could look to implement a Phishing Email Reporting Tool which your employees could easily report a phishing email to the Cybersecurity Team without having to manually write an email or call the reporting hotline. Also, you should look to implement a Labelling mechanism to automatically label all emails received from external Domains as “External”, as this has been proven to be effective in raising the alertness of employees when they receive any external emails, which could potentially be a phishing email or contain malicious artefacts.


Threat Intel and Hunting. A common saying goes “Know thyself and thy adversary to win a hundred battles”, this is very true and applies in the realm of Cyber Defense as well. By having timely intel that are relevant to your threat landscape, it helps you perform sense making and correlation of threats in your environment more effectively and allows you to put in the necessary measures early to look out for such threats. You should also look to conduct regular pro-active threat hunting sessions by trained specialists (i.e. Threat Hunters) to discover low-lying and advanced attacks which could otherwise may not have been picked up by your regular controls.



Given the need to transition quickly,  securely and efficiently to a remote working model for your organization, you will need to be able to make the relevant changes to your existing Cyber Defense Architecture (in the areas of People, Process and Technology) within a short amount of time, in order to ensure that the level of cybersecurity risk which your organization could be potentially exposed to, continues to remain within an acceptable level. As such, it may be worthwhile to consider engaging external professionals for tasks which could be performed remotely, for example:

  • Perform a gap analysis on your existing processes (e.g. Incident Response and Reporting Processes, Access Provisioning Processes) through documents review and remote workshops that are focused on the remote working model and provide practical recommendations on what you can quickly implement to close the gaps.
  • Develop Use Cases that are tailored to the remote working model to ensure that the detection remains effective against the latest threat landscape.
  • Subscribe to a temporary Managed Security Service to outsource your Level 1 monitoring to an external party if you anticipate a surge in the number of alerts in the SOC during a particular period, so that you can free up the time of your internal SOC team to focus on investigation and incident response.
  • Subscribe to an IR Retainer service to implement a surge resourcing model, ensuring that you have sufficiently trained expert resources when needed most, to assist the internal IR Team in times of complex incidents which may require highly complex work such as malware analysis and digital forensics.
  • Conduct threat hunting sessions to discover any low-lying threats which may have been present for some time in your environment.



To conclude, there is no one-size-fit-all solution but we hope that the above will provide you with some useful insights in planning for your Cyber Defense Architecture. 


Security Operation Centre (SOC) comes in different forms (e.g. In-House, Outsourced, Hybrid etc) and sizes, depending on multiple factors such as the objectives and functions that the SOC is meant to serve, as well as the intended scale of monitoring. However, in almost all SOCs, there will always be a SIEM, which basically acts as the brain of the SOC to pick up anomalies by correlating and performing sense-making on the information coming in from various packet and log sources. More than often, the efficiency of your SOC in being able to detect potential breaches in a timely manner, depends very much on the SIEM itself, which includes from having the correct sizing and configuration, being integrated with the relevant data sources, to having the right Use Cases deployed, among others. In this post, we will be focusing on the strategy to plan and develop Use Cases that will lead to effective monitoring and detection in your SOC.  


Prioritise your Use Case Development by Road-mapping

When you are first starting out on your SOC journey, there will be many Use Cases which may come to mind that would cater to different threat scenarios. Most of the SOCs would typically make use of the Out-Of-The-Box (OOTB) Use Cases that are available as a start, however, this will not be sufficient in the long run. Hence, there is a need to also develop your own Use Cases on top of the OOTB ones. The fact is that Use Case development is a lengthy and on-going process, from identifying the problem statement to finetuning the Use Cases, and also coupled with the fact that the threat landscape is constantly evolving. Therefore, it is always important to be able to prioritise which Use Cases to be developed first and one of the best ways to do so, is to come up with a roadmap. 


When it comes to road-mapping for your Use Case development, there are many good open-source references available, such as the MITRE ATT&CK Framework and THE VERIS Framework, which are useful resources to aid you in your roadmap planning, further information can be found in the following URLs - MITRE ATT&CK, THE VERIS However, it is important to note that while such frameworks form good references, they should not be taken wholesale when it comes to planning for your organisation’s Use Case development roadmap, reason being all organisations are unique and therefore not all areas are applicable. Prior to planning for the roadmap, it will be worthwhile to first perform a Priority Analysis, where you can identify the priority areas in which the Use Cases should be focused upon, based on factors such as the following:


  •      Existing threat profile including top known threats,


  •     Critical Assets and Services (note: It is extremely important for an organisation to have in place a well-defined methodology to regularly and systematically identify Critical Assets and Services as the outputs from such identification exercises are integral to many other parts of your security operations e.g. from deciding on the level of monitoring of an asset to assigning the appropriate severity level to an incident.)


  •      Critical Impact Areas to the organisation e.g. Financial, Reputation, Regulatory etc.


With the Priority Analysis being performed, you will then be able to identify which are your “Crown Jewels” and prioritise the protection efforts by developing the relevant Use Cases around them.


The Development Lifecycle

Once the priority areas have been identified, the next step will be to brainstorm for relevant Use Cases in these areas, before developing and finally deploying them into the SIEM. The following summarises the phases in a typical Use Case development lifecycle:


  1.       Define Problem Statement. This highlights the “problem” that you wish to solve (i.e. the threat that you wish to detect) by having the Use Case, and give rises to the objective of the Use Case which you are planning to develop. It is important to note that in planning which Use Case to be developed, the relevancy of a Use Case should not be determined solely based on presence of indicators from the past logs of the environment, because it does not mean that an incident (e.g. breach) that have not happened before will not occur in the future (Refer to the Priority Analysis explained in the previous section for recap on how to identify relevant Use Cases).  


  1.       Develop High Level Logic. Once the objective of the Use Case is clear, the next step will be to develop the high-level logic of the Use Case using pseudo code. This includes identifying the necessary parameters such as the length of the “view” or “window” and the number of counts required to trigger the Use Case. Try to avoid focusing too much on the actual syntax at this stage as this may cloud your thinking and increase the chances of introducing errors into your logic design.


  1.       Identify Data Requirements. Identify the packet and/ or log sources that are required as inputs into the Use Case and check their availability in the production environment.


  1.      Check Live Resource or Internal Library. Based on the high-level logic developed, always try to look for similar and existing Use Cases that are available in the Live Resource (more information at:, community platforms or your own internal Use Case library, instead of developing them from scratch, as this would help to potentially minimize the efforts on development and at the same time reduce chances of human errors.


  1.     Development. Proceed to develop the Use Case in syntax form by either making modifications from existing references or develop from scratch if there are no other alternatives.


  1.     Test & Deploy. Deploy the Use Case in a test or staging environment where possible, and simulate the threat scenario which the Use Case is intended to detect to confirm that the Use Case is functioning correctly, before proceeding to deploy it in the production environment. Note that there is an option in NetWitness to deploy the Use Case as a Trial Rule, more information can be found at:


  1.       Monitor False Positive & False Negative Rates. Once the rule has been successfully deployed into the SIEM, set up the necessary metrics to monitor the False Positive and False Negative rates.
  •  A high False Positive rate is likely to take a toll on the SOC operations in the long run, as unnecessary human resources and efforts would be spent on triaging all the false positives.


  •  Do note that while False Positives can be determined following triage, it is much more challenging to determine and obtain an accurate picture of the False Negative rate, as this is only possible when you happened to learn of an actual breach and where the relevant Use Case failed to trigger in your environment i.e. you do not know what you do not know. In many instances, breaches could go undetected for a prolonged period of time, hence making False Negative rate an extremely difficult metric to be measured. Therefore, it is important to properly test out the Use Case where possible, following initial deployment.


  1.      Finetune. Now, should you stop yourself from deploying a particular Use Case for fear of introducing a potentially high False Positive rate? We all know that high false positive rates are one of the nightmares for an analyst, however, we should not be stopping ourselves from deploying a particular Use Case into the environment simply because of this, reason being the Use Case serves to exist in the first place because of the “problem” that you need to solve (as defined in your Problem Statement). Rather, we should look to deploy, monitor and fine tune the Use Case to reduce the False Positive rate over time. At this point, we have to caution that this is not a one-time process and may require several iterations of review and finetuning over time to eventually stabilise the False Positive rate to an acceptable level.


  1.      Regular Review. Again, as the threat landscape evolves constantly, we should look to put in place a process to conduct regular reviews of the existing Use Cases, finetune or even retire them if they are no longer relevant, in order to maintain the overall detection efficiency of the SIEM.



Now that the Use Case has been deployed into the environment, what is the next step? While the monitoring and detection part of the cycle has been taken care of, it is equally important to also ensure that we have a robust incident response mechanism in place. Apart from the Incident Response Framework which spells out the high-level response process, it is recommended to go into the second order of details to put in place the relevant Playbooks, which are step-by-step response procedures with tasks tagged to individual SOC roles and specific to different threat scenarios. As a good practice, such Playbooks should also be tagged to the relevant Use Cases that are deployed in your SOC. The following diagram summarises how we can make use of the playbooks during the Incident Response cycle depending on the maturity level of the SOC:


  1.       Printed Procedures. This is the least mature method to operate the Playbooks and is generally not recommended unless there are no other suitable alternatives.


  1.      Shared Spreadsheet. This is suitable for small scaled or newly set-up SOCs which are not ready to invest in a SIRP or SOAR yet. For each new case, the relevant playbook template can be pulled out and populated onto an excel spreadsheet (or equivalent) and have it deposited into a shared drive available to all the SOC members, where analysts could update the incident response actions that they have taken while the SOC Manager, Incident Handler or Analyst Team Lead could track the status of the open cases through these spreadsheets.


  1.     SIRP. This is basically an Incident Management Platform which allow the analysts to easily apply the relevant playbooks and update the status of the incidents in a centralised platform. As compared to the spreadsheet method, the SIRP allows for a stricter access control in terms of being able to define and enforce different level of permissions across different roles in the platform, as well as the ability to maintain an audit trail.


  1.      SOAR. This Orchestrator provides a greater degree of automation in the incident response as compared to SIRP, which could potentially cut down the response time and increase the overall efficiency of the analysts.



To conclude, there is no one-size-fit-all solution when it comes to developing the Use Cases in your organisation and one of the recommended ways is to define a short-to-medium term roadmap customised to your environment for Use Case development. The roadmap should also be reviewed and revised from time-to-time to ensure that it stays relevant to the constantly evolving threat landscape. In general, your SOC should have adequate coverage (in terms of monitoring, detection and response) across different phases in the Cyber Kill Chain as shown below:



We hope that you find this useful in planning for the Use Cases to be developed in your organisation and happy building!

Filter Blog

By date: By tag: