Getting Started With
Successful Security Breach Detection
There is a huge operational shift that needs to happen for organizations as they realize they have become the target of hackers.
Organizations historically believed that security software and tools were effective at protecting them from hackers. Today, this is no longer the case, as modern businesses are now connected in a digital global supply ecosystem with a web of connections to customers and suppliers. Often, organizations are attacked as part of a larger attack on one of their customers or suppliers. They represent low hanging fruit for hackers, as many organizations have not invested in operationalizing security breach detection.
As this new reality takes hold in the marketplace, many will be tempted to invest in new technology tools to plug the perceived security hole and move on with their current activities.
However, this approach is doomed to fail.
Security is not a "set it and forget it" type of thing. Defending an organization from a breach requires a careful balance of tools and operational practices -- operational practices being the more important element.
Events, Attacks, Incidents and Responses
​IT departments and support desks have been dealing with tickets and outages for a very long time. Root cause analysis of outages is a good way to start security event identification. Security event identification and response needs to be incorporated into this function and operationalized.
​
​Most security problems start small and increase in severity if they are not addressed in the early stages.
Data breaches are usually preceded by many smaller security events that combine to form a security attack that could be enough to compromise something in the organization. Expanding the number of compromised devices opens access to more data.
Most breaches are initially logged as an "event" (or series of events), which is then identified as an "attack," which is then escalated to an "incident" when a compromise is identified, and then declared and reported as a "breach" if it turns out that data has been stolen or lost.
Often during this compromise process, an availability outage of a device or service occurs. Identification requires experienced resources to complete a root cause analysis, often using a combination of technical expertise and investigative forensic tools. Root cause analysis can help find business issues but is also a great place to start with security operations for breach detection.
Example Investigation
To make this a little more real, here is a 20-year-old example of how a relatively simple event was potentially a serious security breach. We were working with a client, filling in for one of its senior network support staff while they were on vacation.
A standard help desk ticket was created to investigate the root cause of a router failure at one of the sites around lunch time.
Event Status
-
Upon initial investigation, we identified that a router had rebooted outside of a maintenance window.
-
Further investigation identified that the login credentials had not been set on the router.
-
A review of the router logs showed that the router had been rebooted, outside a change control maintenance window.
-
Further review of the logs indicated that administrative activity had occurred outside a change control maintenance window, shortly before the reboot.
-
Investigation into the administrative activity identified the source IP address of the activity was from another site, out of province. This was not a normal part of the network support process. ​
Attack Status
​
-
Further investigation into the administrative activity tracked it to a remote access range.
-
The IP address was assigned to a Unix administrator's login ID, who was not normally responsible for network equipment.
-
The Unix administrator was contacted, and he was at lunch at the time of the attack, not working remotely, but at the office.
-
The Unix administrator called home and found out that his son had been home for lunch from school and had used his father's cached credentials for remote access.
Incident Response
​
No penalties or charges were placed against the son of the Unix administrator, but I have a feeling that he may have had some rather uncomfortable discussions with his father that night.
​
Nevertheless, this does demonstrate how a simple network interruption's root cause was a potentially serious security incident. Follow-up decisions or potential incident responses could have been:
​
•Password reset for the Unix administrator's account
•Improved procedures for setting up network devices
•Changes in policies around cached credentials for remote access
•Configuration management to prevent caching credentials
This example drives home the need for organizations to have security operational processes and expertise available to them on a real-time basis. It also demonstrates how operationalizing security event detection can lead to security improvements. Existing security information and event management (SIEM) tools did not detect the compromise in this example.
Based on the outcomes of these types of investigations, sometimes the learnings can be automated in SIEM tools for the common or repeatable issues.
With the data breach reporting regulations that we have today (e.g. GDPR), organizations need an operational plan for notification and reporting, inside and outside of the organization.
The plan needs to clearly define the requirements for event, attack, incident, and breach notifications and reporting, including:
•Who makes what decisions for notifications, reporting, escalation
•How notifications and reporting should be communicated
•Timing of notifications and reporting
This can be a starting point for developing successful security breach detection capabilities with operational practices, not just tools.
If this breach had been left undetected, the outcome could have been much different. If this security incident had been malicious, as was the case with Target's HVAC service provider, it could have resulted in a significant breach that would have impacted the revenue streams, brand, and potentially loss of intellectual property to members of the supplier ecosystem
--- but it was just a router failure .......... RIGHT?
First Published NoJitter July 18, 2018