Coronavirus Pandemic Challenges Certain Aspects of Enterprise Information Security Strategy

During a localized disaster event, systems and data can continue to be protected if organizations have included their security technology stack and operations within their overall disaster recovery plan and business continuity plan. However, a pandemic situation presents unique challenges for prevention, detection, response, and recovery. Furthermore, it is likely that malicious actors will focus additional efforts to breach your defense-in-depth capabilities during this period.

Identity and Access Management

With most knowledge workers now based out of home offices, at short notice, organizations need to ensure that credentials are not compromised and systems/data are not breached or compromised.

1. Multifactor authentication based upon physical tokens are subject to fobs not working, or misplaced, with no recourse to walk up to the service desk for a new fob. Mobile-device-based soft tokens are relatively easy to deploy compared to the alternative (if regulations allow – bank transactions may still need physical tokens), and access to the service desk over the phone will enable staff to continue to operate securely.
2. If you use a cloud-based identity management solution, confirm with your vendor that all SLAs will be respected, and its business continuity plan is in place, including emergency contact numbers, if you haven’t done so already.
3. Role-based access controls need to be frozen with existing permissions, with rapid response to changes only upon executive approval.
4. Phishing awareness and testing need to continue and perhaps even reinforced, as this is a time of increased distraction among your staff, and credentials compromise is at heightened risk levels.

Vulnerability Management

The cycle of vulnerability scanning, prioritization, and remediation needs to continue, though there are unique challenges under current circumstances.

1. Consider the use of a managed security services provider to assist with the task of vulnerability scanning if you do not have your own scanning toolkit in place.
2. Employees with admin privileges on their local machines may have introduced local vulnerabilities that have not been remediated. Ensure that you scan PCs operating remotely, at an appropriate frequency, and deploy patches and upgrades as necessary. Consider removing local admin privileges based upon business need, if you have not done so already.
3. Test patches in a test environment, or on a less critical group of servers/machines, before broader deployment across the environment. This common practice is even more important now, as end users may not have the option of walking up to the service desk or have a technician do a deskside visit to fix compatibility issues.
4. Prioritize patches based upon criticality and exploitability – a vulnerability in a critical system that is not exploitable (perhaps because it is airgapped) is not a priority fix.

Change Management

Changes to enterprise platforms bring risk yet are necessary to maintain organizational agility in a time of crisis. Right-sizing your change management program to balance the need to have governance controls in place, with the need to serve the rapid shifts in business delivery models, is the essence of optimization.

1. Build a risk matrix based upon impact and likelihood of failure of any given change. These need to be based upon actionable questions that change requestors can analyze and answer, and responses can be validated. An example of a risk matrix is shown below:
   • Risk Matrix: Impact
     
     
     
     
   • Risk Matrix: Likelihood
     
2. Expand your list of preapproved changes: changes that have a low likelihood of failure, a low impact of deviations, and an easy and repeatable rollback plan. These do not need extensive governance mechanisms, even in normal times; however, organizations are often loath to provide “too much” flexibility. Ask yourself if the change meets these criteria, and if it does, then put it on the list of preapproved changes:
   • Impact of failure from risk assessment < 1 (use your risk matrix questions to decide)
   • Likelihood of failure from risk assessment < 1 (use your risk matrix questions to decide)
   • The procedure is repeatable, with the same sequence of activities (or fully automated)
   • The procedure is documented and peer reviewed
   • Governance and verification controls exist
   • Defined in detail (e.g. down to server name or database field)
   • No significant judgement/decision points in the implementation procedure
   • Rollback is trivial
   • Basic IT team expertise (i.e. not dependent on one individual SME)
3. Take a baseline snapshot of the current configuration of critical systems and implement integrity monitoring to catch any changes that occurred within the review period. Linkage with your ITSM platform to correlate approved or logged change requests with actual configuration changes will be a key factor in identifying potentially malicious activity.
4. Reinforce the need to continue technical peer reviews prior to implementing changes for any changes that are not preapproved, especially during times when remediation may be more difficult due to absence of SME resources.