AUTOMATION and digitalisation are major enablers for small businesses in Asia Pacific. Small businesses employ the majority of Asia Pacific populations, and also contribute significantly to the gross domestic product (GDP) in countries in this region.
For example, Singapore’s small and medium enterprises (SME) contribute 48% of the GDP. In Japan, SME contribute 70% of national employment and 50% of GDP, according to the Organisation for Economic Cooperation and Development. In Australia, national employment is a primarily small business, upwards of 97%, while contributing to 32% of the Australian GDP.
The government lead
Cybersecurity incidents continue to increase in number and sophistication, which means the need for effective incident response management keeps ratcheting up. By October 2021, the number of data-compromise incidents driven by ransomware, phishing, and other attacks was already running 27% ahead of the total for all of 2020.
As cybersecurity risks and threats escalate, especially threats such as ransomware and vulnerabilities, the race between businesses and threat actors is down to time, or the speed of identification, isolation and mitigation of threats. This is cyber resilience. In Asia Pacific, the most effective means to enabling both cybersecurity prowess and resilience starts from the government.
In Japan, the Basic Act on Cybersecurity and the Telecommunications Business Act, and the Cybersecurity Management Guidelines since November 2017, present recommendations on threat identification and mitigation, as well as incident response and resilience.
The Australian Government’s Australian Cyber Security Centre has guidelines for managing cybersecurity incidents, including policy definition, detection, keeping an incident register, managing data leaks, handling malware and intrusions, evidence control, and reporting incidents.
The Singapore government has always been especially cognisant of cyber threats, as the small nation is especially digitalised, where residents use digital IDs to sign on to government services, banking, and other transactions.
The Cybersecurity Act 2018 and the earlier Computer Misuse Act both collectively help any entity in Singapore to understand the confines of the cyber arena and what is and what is not condoned. The Cybersecurity Act presents a regulatory framework on managing critical infrastructures, incident response and approved providers ecosystem.
Incident response is the key
As we can see, cybersecurity is all about our response. The faster and more holistic our response to cyber incidents, the faster we can get our business back on track.
The Centre for Internet Security (CIS), one of the foremost international non-profit entities working with global practitioners for cybersecurity, has a set of best practices known as CIS Critical Security Controls, now standing at Version 8. These documents help any business understand how best to deal with cyber risks and intrusions.
One of the key Controls is CIS Control 17, which addresses incident response with three basic safeguards that every organisation should implement. Control 17 also includes half a dozen more safeguards for enterprises, regardless of whether the enterprise works with sensitive or confidential data.
Plan, communicate, test
The basics of CIS Control 17 are 17.1, 17.2 and 17.3. These are the minimum incident response for any entity to start with.
17.1: Organisations need to designate one incident response lead and one backup person. The CIS Internet of Things (IoT) companion guide recommends that organisations also pick a response lead and a backup for IoT incidents, because the threats to unmanaged devices and the appropriate responses differ from IT and managed devices.
17.2: Organisations need to write and continuously update their incident-reporting contact list. It should include anyone who needs to know, such as law enforcement and regulatory agencies, insurers, employees and vendors. Other relevant stakeholders may include shareholders and investors, patients, students or customers. The list may also include public relations contacts for crisis management and media contacts.
17.3: Employees need a written process they can follow to report incidents, including those involving IoT devices. That process should explain clearly what types of incidents or issues to report, who to send the report to, when to report incidents, and how to share the information (for example, via email, phone, instant message or another channel).
In light of privacy laws around Asia Pacific, entities handling sensitive or restricted data should implement steps 17.4 through 17.8.
17.4: Organisations must define all the roles, responsibilities, compliance issues and communication requirements for incident response. Without clear action steps, a team can waste valuable time duplicating efforts and untangling communication threads during an incident response. Unclear roles and requirements also raise the likelihood that critical response steps may be overlooked.
17.5: The right people need to be appointed to the right incident response roles. At the enterprise level, this step requires bringing in people beyond IT and security operations centre from legal, public relations, human resources, facilities and other relevant departments.
17.6: Enterprises need to pre-designate approved communication channels for people involved in the response to use during an incident. They should also choose backup channels, in case the primary channels are compromised. For example, the NotPetya (cyberattacks using the Petya malware) attack took down email systems across enterprise targets, complicating the response for impacted companies.
17.7: Organisations should thoroughly test incident response plans at least once a year using a variety of scenarios, including current IT threats. This step requires identifying the security testing tools your team will need well in advance of planned tests.
17.8: Response teams should follow cybersecurity testing and incident response drills with reviews to see what worked and what needs improvement next time.
CIS Control 17.9 is the ultimate level safeguard if particular entities handle very sensitive data.
17.9: Organisations should set thresholds for incidents, “including, at a minimum, differentiating between an incident and an event”. Setting thresholds will enable your response team to prioritise its work and allow your security team to automate alerts at those thresholds for more efficient responses.
Pitfalls of incident response failures
When security teams lack comprehensive data about their devices and what those devices are doing – or when that data is scattered across different security solutions – it is virtually impossible to launch a fast, effective response to an incident.
To respond properly, security teams need real-time answers to four key questions:
1) Which devices are affected? For example, is the incident unfolding on your organisation’s connected printers, or is it targeting a wider range of devices that share the same IoT operating system?
2) What do the devices control and what do they communicate with?
Devices that control critical infrastructure operations, patient safety, security monitoring and other sensitive tasks require a more urgent response than, say, a Rickroll (an internet prank) breach of connected televisions.
3) What networks are the devices on?
When security teams can see which networks and segments the devices have access to, and whether those limits have been breached, they can more quickly assess risks to other parts of the organisation’s environment and operations.
4) Where are the affected devices?
Connected devices are everywhere, from the production lines and classrooms to operating theaters and executive suites. Understanding where compromised devices are located can help the team prioritise its response.
Untested or incompletely tested plans can fail during a crisis, complicating and slowing down the response. Response delays can worsen the scope of the incident by allowing intruders more time in the system. So the longer it takes to identify an attack and isolate the devices and networks involved, the bigger the disruption can be.
For example, SolarWinds, an American company that develops software for businesses, “saw signs of hackers invading their networks as early as January of 2019, about eight months earlier than the previously publicly disclosed timeline”, but delays in identification and response allowed attackers to stay almost two more years within their system.
Delayed or disorganised responses can also lead to steep compliance penalties. For example, under the General Data Protection Regulation, the European Union requires enterprises to report known data exposures within 72 hours of discovery. Slow incident response has led to costly fines for some organisations, including one travel booking site that was fined US$560,000 (RM2.59 million) for reporting a breach 22 days after discovery.
Miscommunication during incident response can also undermine organisations’ relationships with investors and customers. The resulting brand damage can lead to a decline in stock value, customer churn, and increases in the average cost to acquire new customers.
Leverage intelligence to power your response plan
One of the effective means to optimising an incident response management system is to look for a solution that manages all assets and integrates their existence and information into a unified platform.
Look for tools and information where you can achieve faster, more focused incident response, remediation and recovery. After any incident, you should also have the means to allow your team to leverage on AI (Artificial Intelligence)-powered anomaly detection to identify anomalous device behaviour that can signal an attack. After the incident response, security teams can access the logs for review and forensics.
The world we are in now is accelerating just as cyber threats are escalating and gaining sophistication. How we respond to all threats can literally make or break our operations.
Matt Hubbard, Director, Market Intelligence, Armis, a leading security platform.
