[BreachExchange] Getting Started with Successful Security Breach Detection

[Audrey McNeil]

https://www.nojitter.com/post/240173666/getting-started-
with-successful-security-breach-detection


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.

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

1. Upon initial investigation, we identified that a router had rebooted
outside of a maintenance window.
2. Further investigation identified that the login credentials had not been
set on the router.
3. A review of the router logs showed that the router had been rebooted,
outside a change control maintenance window.
4. Further review of the logs indicated that administrative activity had
occurred outside a change control maintenance window, shortly before the
reboot.
5. 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

1. Further investigation into the administrative activity tracked it to a
remote access range.
2. The IP address was assigned to a Unix administrator's login ID, who was
not normally responsible for network equipment.
3. The Unix administrator was contacted, and he was at lunch at the time of
the attack, not working remotely, but at the office.
4. 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 Status

1. The attack by an outside party was successful and was upgraded to an
incident.
2. We reported the incident to the manager.
3. Further investigation, using data breach forensic tools, resulted in the
discovery that the son had not accessed any data but had gained access to
several other network devices.
4. This was not declared a breach, as no customer data had been stolen or
deleted. The decision not to declare a breach was made by the manager, not
the technical investigator.

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?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.riskbasedsecurity.com/pipermail/breachexchange/attachments/20180719/83e057a5/attachment.html>