This is the third in a four-part blog series. Check out part 1 and part 2.
Part 3 – Security Operations
The Forrester report suggests “The Data Breach Notification requirement will be a game-changer”. Specifically, this means incident response is more critical and difficult: the required information as part of any data breach notification (outlined in Article 33 section 3) includes the scope of the breach and personal data compromised, consequences to individuals and mitigation. Clearly better information, management processes and automation will help in the assessment of any potential breach.
Infoblox can help with the challenge of evaluating potential security events to determine what might be incidents that require a response by the security operations team and supporting them in the subsequent assessment process. Based on our experience there are three areas where Infoblox products and services are relevant to security operations:
- Providing visibility into what is where on the network.
- Delivering curated threat intelligence and tools for investigating Indicators of Compromise (IOCs).
- Automating the process for sharing intelligence and IOCs with security tools.
Knowing What is Where
What does not work is the good old IP Address Management Spreadsheet. Every networking professional has probably used a variant of this at some point – something like one tab per VLAN and one row per IP. This does not realistically reflect what is on the network, nor does it keep up with changes. For instance, anyone who has managed something like this knows that the number of times they are informed of something being removed from the network is probably a round number.
How does this spreadsheet help the security operations team during assessments? It doesn’t. Nor does it help the network team who may be called to find out what is really associated with an IP address.
An integrated DDI system that combines “The Spreadsheet”, incorporates live DNS & DHCP data, is updated by active discovery of both the physical and virtual infrastructure, all combined with network authentication events, is a much better approach. This gives the answer to “who”, “when” and “where” based on the protocols themselves and the information from the network itself.
Having this data in a multi-user system, with role-based administration capabilities, frees the networking team from calls to investigate the “who”, “when” and “where” and enables the security team to look at this information directly. It also becomes a virtuous circle in that the greater the accuracy of the data the more it is used, and hence the more it can facilitate automatically provisioning IPs and domain names, so the more accurate it becomes. Visibility into the network will speed up assessment, saving cost in terms of operator time, and allow some more proactive action (why is there a PlayStation or XP system still on the network?).
Don’t forget IPv6! Yes you are running it. You can either leave it to grow up organically (like was done with IPv4 – remember?) or take control of the address plan now so that you know what is where when you see IPv6 addresses in log files. Something is bound to exploit IPv6 as currently partially implemented within corporate networks. For an example see Tom Coffen’s presentation “Delivering on the Promise of Modern Data Centers: A focus on DNS and IPv6 ” ref 3 where IPv6 DHCP is mentioned. When IPv6 addresses appear in security logs how will you know what is where if you don’t have an address plan?
Think of improving the data quality used for security and network operations as below:
Turning Data into Actionable Information
This can be summed up as combining the current data you have from the sources on the left and using this to provide the benefits on the right of the security and networking teams using the same data, enabling automation and providing a valuable database of information.
Lastly, a tip from CISOs: co-locating security and network operations with good data sources has worked wonders for addressing security issues and breaking down “silos” within an organisation. This will certainly help in assessment and responding to security events.
The action item here is to review how accurate and integrated DDI is within your organisation as a basic component of being able to assess risk, alerts and incidents. If you are already there and it’s working well for you move on to look at automation and reporting.
Threat Intelligence and Investigation
Knowing what is where is useful in terms of assessing security risks and the impact of malicious activity. This goes hand-in-hand with knowing if there is something to worry about in the first place.
Most organisations are using threat intelligence unconsciously in that they may be consuming a feed to something such as a web proxy to block potentially harmful http(s) traffic, i.e. they block what the proxy vendor says they should block.
Threat intelligence can be used independently of any specific tool, indeed in many cases it can augment any feed supplied by a specific vendor. One of the interesting facts about threat intelligence data is that the overlap between feeds is surprisingly little, so multiple data sources tend to be a benefit and not duplication.
By using threat intelligence as a data source or feed in its own right, rather than as an embedded part of any specific security implementation, you can achieve the following:
- “Arm” the DNS choke point in the form of Response Policy Zones.
- Add IOCs to firewalls or proxies.
- Use the information in the SIEM and/or SOC for automated threat assessment.
- Have a source of information for the manual investigations that a security operations team undertakes.
The action item here is to review if using threat intelligence would benefit your organisation. In the context of GDPR if you have no process to assess IOCs other than a web search, then reviewing what is available to support investigations should be a priority. Using a consolidated threat intelligence feed and associated tools is likely to save time to any security operations centre and does allow an organisation to demonstrate a process is in place. It also provides a vendor supported approach with a consistent interface, so any investigative tool knowledge does not leave with the person who created the in-house tool-set. It won’t replace high level expertise, but the starting point will be much higher than a search tool.
Infoblox gathers and maintains its own threat intelligence and partner data, and offers tools for security operations to access this information for automation/investigations. Infoblox combines its own with other available threat intelligence data feeds on the Threat Intelligence Data Exchange (TIDE) platform and provides an API and GUI to use the data. Contact Infoblox for more information.
Automation
Assuming you have a combined authoritative DDI data and processes then you can use automation, reporting and integration to reduce risk and help with assessments. Examples include:
- Do I have any old XP devices lurking on the network? Can I prevent them getting an IP address in the first place?
- A new device has been added, automatically start a scan of the endpoint using a vulnerability scanner.
- A DNS query takes place to resolve a malicious domain name. The requestor’s IP (source) address of the query is passed automatically, by the DNS service itself, to a security tool that quarantines or remediates an endpoint. Alternatively the DNS service returns a query response that is the IP address of a honeypot.
- Combining DDI data with critical SIEM alerts. For instance, add context such as a source IP being from a data centre VLAN, a VLAN used by Human Resources or a guest wireless network – each may indicate a different priority. Threat intelligence data may also be added based on the IOC.
- Collect DNS query data to help with the “we don’t know what we don’t know” problem in securing any network.
Automating compliance to industry security standards such as PCI can be used, in a GDPR context, to demonstrate “state of the art” referred to in Article 25 section 1. While the GDPR does not specify any standards to be adhered to, ensuring compliance with an industry standard and having the audit records to show this, will help with any regulatory authority if the worst happens.
Security operations could mandate a standard and ask a team such as the network group to adhere to it, or both groups could use the same tools to automatically ensure compliance. The second approach is likely to be more successful and has the benefit of an audit trail. The automated approach would do this as configuration changes happen, to ensure compliance is maintained, independently of the human factor.
Checklist for Security Operations
Below is a checklist aimed at helping improve security operations, including closer cooperation with network operations:
- Foundational information
- Do you know what device is where on the network?
- Can you leverage this to reduce risk?
- Share intel across functions (network and security operations) and enforcement points
- One view of the network, accessible by all?
- Threat Intelligence; is this being leveraged?
- Are you combining intelligence from various sources?
- Is your intelligence current and comprehensive?
- Is it easy to use and access?
- Are you paying for the same intel on different platforms instead of sharing?
- Evaluate whether using free or self-build threat investigation tools is the right approach
- Will it provide the building blocks for automation – free may not
- Is the knowledge of any in-house tools a risk?
- Conforming to “state of the art” standards
- Can you automate checking compliance?
- Audit trail to prove this?
About the GDPR Blog Series
This blog is part of a four-part blog series. Please find the links to other parts below.
- Part1 – Introduction – Introduce the implications of GDPR to network and security professionals
- Part 2 – Architecture review – Identify and reduce risk, focusing on DNS as a point of control and visibility.
- Part 3 – Support of security operations – Assess the impact of potential malicious network activity along with information sharing, enriching context and signaling between security tools.
- Part 4 – Governance around DDI data – DDI data really helps in terms of network security but some of it will fall under the GDPR as some DDI data relates to a person.