Personally identifiable information (PII) Examples

Personally identifiable information (PII) Examples

PII is any data that could potentially identify a specific individual. Any information that can be used to distinguish one person from another and can be used for de-anonymizing anonymous data can be considered PII.

 

Examples

  • John Smith + Trustwave = GDPR
  • John Smith + Phone Number = GDPR
  • jsmith@trustwave.com = GDPR
  • PII; car number plate, national insurance , passport number, NI Number all = GDPR
  • 407 Southway Drive Plymouth + John Smith = GDPR (fictitious address)
  • Post Code + car reg = GDPR
  • Medical record = GDPR
  • Cookies = GDPR
  • IPaddress = GDPR
  •  Princess Diana  does not apply to GDPR as she has deceased.
  •  Prince William = GDPR
  •  Essentially any information that can identify a living person can be in scope of GDPR even indirectly can come into scope of GDPR:
  •  For example if I was to write a blog then just by the content of the blog if I can be identified , i.e. by style of writing or subject it could indirectly come into GDPR
Advertisements

Incident Response

Incident Identification

Step 1: Prepare your documentation

You will need to document all your activities, from meeting minutes and decisions down to commands typed into your systems by your incident response team.

 

For each step, you will need to record, at minimum:

  • Identifying information (location, serial no, model no, hostname, MAC address, IP Address)
  • Name, title, and phone number of each person who collected or handled evidence during the investigation
  • Time and date (including time zone) of each occurrence of evidence handling
  • Locations where the evidence was stored

Step 2: Assemble your Team

Get your incident response team together! Where possible use phone communication – your email and chat systems may be compromised and you might tip off an attacker that you are aware of them.

You’ll need a broad set of people:

  • Security personnel, including incident responders
  • System and network administrators
  • Business stakeholders, such as PR

Remember! Apply a need-to-know policy for now – no need to blow it out of proportion just yet.

Hint: If you have Cyber Insurance, notify them of a potential claim.

Step 3: Determine Scope

Working with your team, determine as best you can what devices have been compromised.

Assume the worst – that more of your environment is compromised. Yes, it will increase the scope of the response, but will reduce the chance of an incident recurring.

‘Indicators of compromise’ are unexpected or suspicious behaviour which may mean an incident has occurred. This may include behaviours such as:

  • Strange or unexpected system activity
  • Alerts from a Network IDS or Antivirus system
  • Unscheduled system crashes or server reboots
  • Unexplained configuration changes, unusual files, unknown processes, unexpected web-site changes, etc.
  • Influx of phishing e-mails, spoofed e-mails, etc.
  • Unusual activity in log files, or gaps in or missing logs
  • E-mail system showing a large number of bounced/invalid emails
  • Large volumes of network traffic to unknown countries and networks

Containment

Step 1: Contain to Affected Systems.

A hacker will try to traverse to other systems, so isolate affected systems as soon as possible. The goal here is to prevent the problem from getting worse.

There are some key actions – these may affect incident response, forensic, and legal activities, so make sure you do it right:

  • Do unplug the network cable of affected systems
  • Do suspend affected VMs (a copy of the RAM is taken, which is important for forensic analysis)
  • Do disable wireless connections (in order of preference: at the router, hibernating the laptop, then disconnecting via the computer operating system)
  • Do declare an incident, if it appears to be one
  • Don’t run an anti-virus scan (this changes timestamps)
  • Don’t shut down operating systems

Step 2: Backup affected systems

You want to keep copies of the affected system for forensic purposes.

The best approach is to remove the affected system from the environment, and provide a new system for the user, or build a new server from a clean SOE.

Of course, sometimes this isn’t possible, in which case you should:

  • Obtain a brand new disk drive and create a complete bit-for-bit backup; and
  • Get another copy on write-once media (CD-R or DVD-R) in the event that you need pursue legal recourse.

Hint: Use the ‘dcfldd’ tool, which is available for Unix and Windows.

3rd party forensic investigators will have disk cloning hardware to perform this task if you don’t have the relevant expertise.

Eradicate the Problem

Step 1: Remove the malicious code

Eradication means removing the problem from affected systems determined through your scoping efforts.

The actual technical actions for eradication may vary considerably.

Hacking

For attacks on vulnerable systems, cleaning the system and patching the system may be sufficient.

Malware outbreaks

It can be very difficult and time-consuming to verify that systems are in fact secure, and malware has been completely removed. Rootkits in particular need specialist skills to detect.

We recommend rebuilding systems affected by malware, by either:

  • Reinstall the operating system from original media or image, and restore data from the last known good backup onto new media;
  • Wipe the existing media, reinstall the operating system from original media, and restore data from the last known good backup;

See the eradication tools in the Links below.

Step 2: Apply compensating controls

If you have indeed been breached, it will be best to apply further controls to ensure you are better able to prevent and detect malicious activity next time.

These controls may include:

  • Additional logging and monitoring of systems, applications, and databases
  • Increased monitoring of infrastructure logs, such as SIEM, firewalls, and IDS/IPS
  • Restriction of logical access to databases
  • Additional network segmentation
  • Restrict access to databases

Recovery

Step 1: Recover your systems

Once you’ve eradicated the problem, you can recover the affected systems and return them to production.

Remember to check the integrity of your backups before restoring from them. Malware may have been backed up with your system and data files.

There are key actions when you recover your systems:

  • Do patch all affected systems
  • Do check and remediate the original attack vector
  • Don’t re-introduce the vulnerability from your backups

Step 2: Monitor your environment

You need to conduct logging and monitoring of systems and network traffic to verify that the system or environment has been remediated.

  • Setup a sniffer on a switches span port to capture all network traffic
  • Log all traffic and send to your logging and monitoring solution
  • Check for further activity on the network

If you’re satisfied that the attack has been completely eradicated, then you can formally terminate the incident and conduct post-incident activities.

Have a look at our Incident Response Guide (available to subscribers) for supporting information on conducting post-incident activities, and preparing for the next security incident.

Incident Response Flow Chart

 What to capture

  • Network Diagram
  • Internal LAN IP Address(s)
  • External WAN IP Address(s)
  • Log Files
  • Firewall
  • IDS / IPS
  • Web / Proxy Server
  • Other Application Logs as Needed
  • PowerShell ▪ SQL
  • RDP
  • DNS
  • Active Directory
  • Disk Images for Affected Systems
  • Forensic Image of Disk
  • Volatile Memory Capture o Event Logs
  • Specific Application Logs
  • Detailed Timeline Prior to Engagement

Links

Eradication Tools

Microsoft Malicious Software Removal Tool
Avira Rescue System
McAfee Stinger Malware Removal Tool

Incident Reporting

Australian Cybercrime Online Reporting Network (ACORN)
CERT Australia

Data Breach Infographics and Cyber Security Research Reports

Data Breach Infographics

Cyber Security Research Reports

Security operations and analytics platform architecture (SOAPA)

Security operations and analytics platform architecture (SOAPA)

Security information and event management (SIEM) systems have been around for a dozen years or so. During that timeframe, SIEMs evolved from perimeter security event correlation tools, to GRC platforms, to security analytics systems. Early vendors like eSecurity, GuardedNet, Intellitactics, and NetForensics, are distant memories; today’s SIEM market is now dominated by a few leaders: LogRhythm, McAfee (aka: Nitro Security), HP (aka: ArcSight), IBM (aka: QRadar), and Splunk.

Of course, there is a community of innovative upstarts that believe that SIEM is a legacy technology. They proclaim that log management and event correlation can’t keep up with the pace of cybersecurity today, thus you need new technologies like artificial intelligence, machine learning algorithms, and neural networks to consume, process, and analyze security data in real-time.

 

As an industry analyst, I should be waving my arms around madly, proclaiming that “SIEM is dead,” since that’s what those in my profession tend to do. Sorry, but I don’t think SIEM is dead at all. Instead, enterprise security operations and analytics requirements are forcing rapid consolidation into something new that ESG calls a security operations and analytics platform architecture (SOAPA).

Within SOAPA, SIEM -like functionality still plays a starring role, often aggregating analytics data into a common repository. But unlike the past, SIEM is one of several security tools within SOAPA, and these technologies must be designed for asynchronous cooperation so security analysts can quickly pivot across tools to find data and take action as they need to in real-time.

SOAPA is a dynamic architecture, meaning that new data sources and control planes will be added incrementally overtime. I do believe, however, that today’s SOAPA is built with SIEMs (or similar log management and search products/services) and:

  • Endpoint detection/response tools (EDR). Security analysts often want to dig deep into security alerts by monitoring and investigating host behavior so EDR (i.e. CarbonBlack, Countertack, CrowdStrike, Guidance Software, etc.) is an essential component of SOAPA.
  • Incident response platforms (IRPs). Aside from collecting, processing, and analyzing security data, cybersecurity professionals want to prioritize alerts and remediate problems as soon as possible. These requirements are giving rise to the rise of IRPs like Hexadite, Phantom, Resilient Systems (IBM), ServiceNow, and Swimlane.
  • Network security analytics. SIEM’s log analysis and EDR host behavior monitoring are complemented by flow and packet analysis in SOAPA, provided by vendors like Arbor Networks, Blue Coat/Symantec, Cisco (Lancope), RSA, etc.
  • UBA/machine learning algorithms. While these tools have received an inordinate degree of industry hype, there’s little doubt that machine learning will be baked into security analytics henceforth, thus vendors like Bay Dynamics, Caspeda (Splunk), Exabeam, Niara, Sqrrl, and Varonis should be included in SOAPA.
  • Vulnerability scanners and security asset managers. Part of security operations is knowing which alerts should be prioritized. These decisions must be driven by solid data from vulnerability management systems (i.e., Qualys, Rapid7, Tanium), and other tools that monitor the state of systems and network configurations (i.e., RedSeal, Skybox, Verodin, etc.).
  • Anti-malware sandboxes. This technology represents another key pivot point for understanding targeted attacks that may use zero-day malware. Sandboxes from FireEye, Fidelis, and Trend Micro are definitely part of SOAPA.
  • Threat intelligence. Enterprise organizations want to compare internal network anomalies with malicious “in-the-wild” activities so SOAPA extends to threat intelligence sources and platforms (i.e., BrightPoint [ServiceNow], FireEye/iSight Partners, RecordedFuture, ThreatConnect, ThreatQuotient, etc.).

Aside from the technologies themselves, here are a few other thoughts on SOAPA:

  1. Beyond data exchange between security tools, the next big innovation will be central SOAPA command-and-control for analytics and management (i.e., configuration management, policy management, etc.) of the security infrastructure.
  2. The market is already moving in SOAPA’s direction. Witness IBM’s acquisition of Resilient Systems for IRP, Splunk’s purchase of Caspida for UBA, and Elastic Search’s acquisition of Prelert.
  3. Now that McAfee is independent of Intel, look for it to invest in its enterprise security manager (i.e., Nitro). McAfee will also accelerate SOAPA technology integration with its own tools and ecosystem partners, and acquisitions aimed at filling architectural gaps.
  4. Given the central role that SIEM still plays in SOAPA, someone (CA? Palo Alto? Symantec? Trend Micro?) will buy LogRhythm.
  5. Each of the technology elements described above could be delivered on-premises or via SaaS options. SOAPA must be flexible to accommodate these options.
  6. SOAPA must be built for immense scale – especially as organizations increase their use of cloud computing and IoT. It’s likely cloud analytics or storage will become part of the architecture.
  7. A few vendors may be able to deliver their own proprietary SOAPA solutions but enterprise customers will likely eschew single vendor solutions while anchoring their SOAPAs with lead vendors and ecosystem partners. Small enterprises and SMBs could buy from a single product or SaaS vendor however.

Cyber Security Frameworks

 

Cyber Security Frameworks