This blog looks at the increasing volume and frequency of software upgrades and explores how your information security team can take control of the change process and improve situational awareness.
Roadworks ultimately improve the quality of a road and potentially its effectiveness, however initially it adds risk to road users. Just like roadworks, system upgrades require close monitoring and change management.
The rate at which vendors publish patches and software upgrades has dramatically increased in recent years, with businesses gaining the benefit of these continuous cycles of product improvement. These changes improve systems, their performance and their capabilities. Yet, they also introduce operational risk: information security managers are asking how they can satisfy this growing demand for change and yet maintain the security of their systems and data?
The importance of Operational Change Management
An Information Security Management System (ISMS) is a collection of processes, documentation and operational artefacts (trackers, work instructions and service requests) that organisations use to manage information security. International standard, ISO 27001, is the most widely accepted security standard for information security management systems and includes a myriad of controls to manage the security of system change. The process for change, as identified by ISO 27001, is as follows:
- Identification and recording changes;
- Planning and testing changes;
- Assessing the business impact of changes;
- Soliciting stakeholder approval for changes;
- Verification that security requirements have been met;
- Communication of changes to stakeholders;
- Developing rollback procedures in case of failure or unforeseen events;
- Testing changes in representative test environments; and
- Deployment of changes into the production environment.
Changes to any environment demand higher levels of risk/change management. The service management team must work closely with the information security team to successfully deploy modifications; particularly those emergency changes which often require shortcuts to the standard procedure to enable rapid implementation.
Documenting changes is fundamental to success
Irrespective of the nature of the change introduced, there should be a record of its provenance and reason for introduction; it needs to contain all the relevant approvals and documentation associated with its deployment. This audit record can, if necessary, assist in tracing problems associated with the change.
If businesses don’t have control of the change process and don’t monitor the introduction of application and system updates, it can lead to unexpected and therefore unplanned consequences, including security failures affecting information confidentiality, integrity and availability.
The importance of information asset monitoring is covered in this paper
Using the Audit Trail to Measure Cyber Posture
System and application event logs can be used to monitor systems and users. They become useful sources of information for monitoring the effect a change has on the business (be that positive or negative). From an information security perspective, the ISMS documents standard operating procedures (SOPs) for change introduction, along with SOPs for handling exceptions, faults and backouts. There are a variety of threats that the introduction of changes pose to businesses, so by auditing changes and correlating event logs against an appropriate threat model, changes that are harmful can be detected and fixed before any damage is done.
To monitor and report on the organisation’s security posture as changes are introduced, security teams need quality data from audit logs, including the following information:
- Records relating to the change request recorded in the service management tool;
- Description of assets affected by the change (target);
- Assessment of the business impact the change has on target assets;
- Approvals from stakeholders for standard and emergency changes;
- Date and time window for when the change will be deployed;
- Records of successful and unsuccessful installation attempts; and
- Records of successful and unsuccessful access attempts.
Your security team can respond to changes that appear unusual or overly risky, especially if they adversely affect the organisation’s security posture. The use of system privileges or special administrative utilities that may be necessary to expedite an emergency change require particular attention; if they are not specified as required in the change’s documentation, they may be indicative of an attack (or at least worth investigating).
Your SOC team should assess any files accessed during the change process and record the system accounts used to install that change. If the change is anticipated to be installed by a user account, but it’s being installed by an administrator or system account, it’s time to investigate why this is so. It could be that the change is an attack.
Developments in Cyber Threat Modelling
Protecting your business from cyber-attackers requires your security team to assess and tune their security monitoring systems. A commonly used platform used by SOC teams is a Security Information and Event Management (SIEM) system; it helps security analysts determine which files have been accessed and report on the nature of that access. The SIEM records the IP addresses and network protocols used for the system change and reports on unusual behaviour requiring analyst follow up.
As your analysts develop familiarity with the business processes and better understand the nature of the change, they should use the correlation capabilities of their SIEM to assess the change against a threat model. If it looks unusual or suspicious, they can raise the alarm and begin the incident investigation.
Moving on from the retrospective approach to Threat Modelling
The retrospective approach to developing SOC alarms works, and it’s been the mainstay of SOC activities for many years, but it is slow and protracted and manually intensive. Modern SIEMs collect all the vital information in seconds and even learn what “good” behaviour looks like; if anomalous activity is detected it is immediately alerted for analyst investigation.
Take Steps to Improve your Organisation’s Situational Awareness
Threat modelling is a process by which SOC teams model how an attacker might target and breach their systems. By collaborating with a penetration tester your analyst can shorten the time it takes to model attacks because they can mimic the attacker’s mindset and how they would introduce malware into your systems. To hack into your organisation, a penetration tester causes systems to react in the same way that they would if they were under a malicious attack. By emulating a hacker, your analysts can then develop rules in the SIEM that detect the kinds of tools, behaviours, protocols and malware signatures associated with those techniques.
To close the change process loop, your analysts can now search the service management tools for approvals for behaviours, and compare the actual filename, file version, or account name with the expected change to key attributes. If another rule, based on the threat model changes, triggers, as part of the process, even if some of the basic information looks right, the analyst can still start the investigation process as there are indicators of compromise that can’t be ignored.
Products
Solutions by Industry
Learning & Resources
About Huntsman
