Managed Security Services Best Practices Guide

January 2020

Table of Contents

Purpose ...... 5 MSS Best Practices Framework ...... 5 Service Initiation ...... 6 IBM Security Solutions ...... 6 XFTAS Configuration Best Practices ...... 8 The X-Force Advantage ...... 12 No Logs Received (NLR) Device ...... 13 Best Practices ...... 13 Baseline Device Policy ...... 16 Best Practices ...... 16 VSOC Portal Reports ...... 18 Best Practices ...... 18 Event Counts by Source IPs ...... 19 Event Counts by Event Names ...... 19 Event Counts by Sensors ...... 20 Vulnerability Management Best Practices ...... 28 Ongoing Operations ...... 30 Device Tuning Best Practices ...... 31 Example: No Risk Scenario ...... 32 Example: Acceptable Risk Scenario ...... 32 Unmanaged Assets Best Practices ...... 38 Policy Change Request ...... 41 Best Practices ...... 41 Security Incident Classification and Escalation Best Practices ...... 49 Security Event Data ...... 50 Security Incident Categories ...... 51 Security Incident Priority Levels ...... 53 Escalation Paths ...... 55 Internet Emergencies ...... 57 Widespread Internet Worm Infections ...... 57 Problem Resolution ...... 58 Security Operations Center Escalation Best Practices ...... 59 Incident General Information ...... 60 Incident Details ...... 60 Incident Management ...... 62 Best Practices ...... 62 Addressing Different Incident Types ...... 63 Gathering Incident Details ...... 65 General Security Escalations ...... 66 Ticket Escalation ...... 66 Management Escalation ...... 66 IBM Security – Managed Security Services Client Enablement

Client Security Organization ...... 70 MSS / Client Interaction Model ...... 71 Management Reports ...... 72 Best Practices ...... 72 Security Manager Overview Report ...... 72 Service Level Agreement Report ...... 73 Service Overview Report ...... 73 Client Roles and Responsibilities Best Practices ...... 74 Security Analyst ...... 74 Security Intelligence Analyst ...... 75 Manager of Information Security ...... 75 Support Roles Best Practices ...... 77 Using the VSOC Portal to Manage Support Roles ...... 78 Service Line and Role Options ...... 78 Creating a PIN and Pass Phrase for Security Contacts ...... 79

IBM Security – Managed Security Services Client Enablement

Overview

This document is a collection of articles around best practices for using IBM Managed Security Services (MSS). Use this as a reference in your security management role, and to help build a long-term strategy that supports your organization in its use of IBM Managed Security Services.

If you have questions, or would like to provide comments or suggestions related to these MSS Best Practices, please e-mail your feedback to: [email protected]

Important: If you are a new IBM client or a new VSOC Portal user, you can access MSS Education resources to learn more about your IBM services, as well as key Portal features and navigation. In VSOC, select Support>Education for more information.

IBM Security – Managed Security Services Client Enablement

Purpose

The IBM Managed Security Services (MSS) Best Practices are based on lessons learned from working with thousands of clients. This guidance should serve as a useful baseline to help you maximize your organization's security investment.

MSS Best Practices Framework

The MSS Best Practices framework consists of multiple ongoing processes and complementary tasks that are optimized to enhance the overall security of your organization. This document is broken down into each framework category: Service Initiation, Ongoing Operations, Problem Resolution, and Client Security Organization. Explore each section to get more familiar with each Best Practice category and its corresponding practice areas.

Note: Feature sets may vary based on the MSS services you have subscribed to.

IBM Security – Managed Security Services Client Enablement

Service Initiation

The Service Initiation area of IBM Managed Security Services Best Practices focuses on the deployment, initial configuration, and client onboarding activities that take place when your service is first set up. The following diagram shows the milestones associated with a typical service initiation project.

IBM Security – Managed Security Services Client Enablement

IBM Security Services

To learn more about what it takes to build a healthy security environment, please contact your IBM Security Services representative or visit the link below: https://www.ibm.com/security/services

IBM Security – Managed Security Services Client Enablement

XFTAS Configuration Best Practices

As a best practice, MSS recommends that you subscribe to the X-Force Threat Analysis Service (XFTAS) during service initiation to take advantage of the security intelligence generated by the IBM Security X-Force research and development team.

X-Force Threat Analysis Service Overview

X-Force Threat Analysis Service (XFTAS) security intelligence information helps you proactively manage daily security threats, providing an evaluation of global online threat conditions and detailed analysis tailored for your needs. XFTAS consists of a blend of trusted security intelligence from the IBM Security X-Force research and development organization, and from threat data collected from IBM's international network of security operations centers. This powerful combination of security research and data, which is summarized in the X-Force Threat Analysis page of the VSOC Portal, clarifies the nature and severity of Internet-based threats. The X-Force Threat Analysis page organizes information into several sections (defined below), including:

• Current Security Assessment • Vulnerabilities - Summary • IBM Security Links (X-Force Exchange) • AlertCon 5-Day Forecast • Alerts / Advisories • Worms & Viruses • Security News

IBM Security – Managed Security Services Client Enablement

Note: To access a roll-up of the XFTAS information available in the Portal, from the Intelligence menu, select X-Force Threat Analysis.

Current Security Assessment

The Current Security Assessment section provides access to a summary of the important events and product releases that could impact your network security. Following each summary, there are related links to help you access more detailed information.

Vulnerabilities - Summary

The Vulnerabilities - Summary section includes a matrix that shows the number of vulnerabilities, by category, over the last 90 days and since your last Portal login. This matrix filters data by your profile, as defined in XFTAS Preferences, and also shows trends across all available vulnerability data. The Vulnerabilities - Summary section provides an at-a-glance assessment of vulnerability trends with potential for impact on your network and on the Internet as a whole.

IBM Security Links

The IBM Security Links section provides access to important IBM resources, including web pages, reports, and other documents that can help you maximize the value of your IBM services.

AlertCon 5-Day Forecast

The AlertCon 5-Day Forecast sections provides an assessment of the current and anticipated threat level of online attacks, providing a real-time indication of the Internet threat environment. The AlertCon service can help you quickly assess the likelihood of an attack against your network assets, and focus resources on the critical security areas that put your infrastructure at risk. The AlertCon levels and their criticality are listed below:

AlertCon 1 - Regular vigilance. Ordinary activity compromises an unprotected network minutes to hours after first being connected to the Internet.

IBM Security – Managed Security Services Client Enablement

AlertCon 2 - Increased vigilance. Vulnerabilities or threats to computer networks require vulnerability assessment and corrective action.

AlertCon 3 - Focused attacks. Specific vulnerabilities and weaknesses are the target of Internet attacks and require immediate defensive action.

AlertCon 4 - Catastrophic threat. Critical security situations within a network dictate an immediate and focused defensive action. This condition may be imminent or ongoing.

Alerts & Advisories

The Alerts / Advisories section includes XFTAS priority alerts and advisories that deliver breaking information on threats. This includes security advisories that contain new vulnerabilities researched by the X-Force, as well as solutions to manage and resolve the threat. Security alerts are timely compilations of threat information from both IBM and from US-CERT.

The top three alerts and advisories are listed in the Alerts and Advisories section. To view a complete list of daily threats and their descriptions on the Alerts / Advisories page, click the “View All” link. Historical information is also available from this page.

Note: Historic information prior to 2017 is available within the VSOC Portal. The data from 2017-Current is available on the IBM Security Link named X-Force Exchange.

Worms & Viruses

The top three worms and viruses are listed on the Worms & Viruses section. Click the View All » link to see a complete list of daily worms and viruses and their descriptions on the Worms & Viruses page. Historical information is also available.

Security News

The Security News section provides an aggregated view of the top security news stories compiled by XFTAS. Click the View All » link to view additional stories on the News page. This page shows stories for the last 30 days by default, but you also can use filter options to search for older news titles, including archived articles.

IBM Security – Managed Security Services Client Enablement

Email Notification of Threat Assessments and Alerts

As an XFTAS client, you can subscribe to daily newsletters that provide insightful information about the day’s issues, emerging threat trends and their impact, and a tailored list of vulnerabilities, threats, and news articles that pertain to your business.

You also can subscribe to a customizable daily threat assessment e-mail that provides:

• Overview of the most important cyber threats • Compilation of published vulnerabilities, worms, viruses, and security news • Graphical representation of the top five TCP/UDP ports reported during the previous 24-hour time period • IBM protection advisories and alerts, and daily AlertCon information, which indicates the current and expected threat state of the Internet

XFTAS Preferences

The XFTAS Preferences page allows you to customize your vulnerability watch areas by product platform, business sector, and geographical region. This page also allows you to enable e-mail notifications, and to select the e-mail format (HTML or text).

To access the XFTAS Preferences page:

1. From the Intelligence menu, select XFTAS Preferences.

Note: If you are on the X-Force Threat Analysis page, you can access XFTAS Preferences by clicking the Modify link displayed below the Profile/Vulnerability matrix.

2. Use the links on the left to view and select options for:

• Vulnerability Watch List – select platform categories, or search by keyword (for example, HTTP) • Business Sector – select industry preferences • Region – select geographical areas • Email Preferences – indicate text, html, or no email notification

IBM Security – Managed Security Services Client Enablement

3. To save your preferences, click the Save button.

XFTAS Support and Inquiries

E-mail support is available to all XFTAS subscribers, with most submissions answered within 24 hours. The XFTAS Team is also available for account administration and general content inquires. In both cases, send e-mail to: [email protected]

The X-Force Advantage

Many organizations lack the time and resources to research and analyze security intelligence on a 24x7x365 basis. Consequently, administrators are forced to react to threats rather than actively anticipate and prevent them. This inability to proactively manage security events and vulnerabilities often leads to poor resource management and to unnecessary interruptions of normal business operations.

The X-Force Threat Analysis Service uses security intelligence gathered and analyzed by the X-Force to deliver high quality, timely, and targeted information on Internet-based threats. This information, delivered from a trusted, reliable source, provides near real-time global threat analysis that can help you take more decisive, proactive measures to protect your infrastructure from attacks or misuse.

IBM Security – Managed Security Services Client Enablement

No Logs Received (NLR) Device Best Practices

The No Logs Received (NLR) area of IBM Managed Security Services Best Practices focuses on ensuring that device logs are being received and stored appropriately.

IBM MSS monitors live agent feeds via an automated system. If a problem is detected, the system generates a No Logs Received (NLR) ticket. The NLR threshold is based on the time elapsed since the last log was received by MSS. The threshold is set dynamically for IDS/IPS devices.

NLR Threshold Adjustments

IDS traffic patterns vary across different networks. Consequently, the Security Operations Center (SOC) may need to adjust the NLR threshold for some of your devices to avoid false positives or false negatives. Common situations that impact the threshold calculation include quiet network segments, low traffic servers, or network or host resources that may be used only during standard business hours.

For some IDS devices, the SOC also has the option to enable or create a signature that fires on a regular timed interval to validate function. For example, IBM IDS/IPS products have a signature called SensorStatistics that can be set to trigger regularly and report various network statistics. This makes it clear to the SOC that the inspection process is running and analyzing data during quiet periods.

Note: The NLR threshold is set dynamically on a per device basis. The dynamic threshold is calculated from past logging trends to make sure it is appropriate and has the best chance to identify anomalies in log flow that could indicate a valid problem.

IBM Security – Managed Security Services Client Enablement

NLR Ticket Troubleshooting

A SOC engineer performs initial NLR ticket troubleshooting. After validating the ticket is not a false alarm, the engineer attempts to resolve the problem. In many cases, the issue is quickly resolved, and the ticket is closed. However, if additional information or local hands-on support is required, the engineer will contact the designated escalation client contacts for the problem devices.

Common Causes of NLR Issues

Common causes of NLR issues include:

• Logging agent or process has been stopped

• IP address change for the reporting interface

• Firewall rule change that is denying the log traffic to IBM MSS

• Network latency

• Traffic not routed to the monitoring interface

• NIDS device sits in the passive segment of an Active/Passive High Availability (HA) network environment (Please advise the SOC if your device exists in this type of network.)

• Time setting is incorrect on the device, causing incorrect event timestamps

Many agents have a local queue for storing logs, so after the NLR issue is resolved, the logs should backfill, with no gap in coverage. For monitored IDS/IPS logs, the backfilled logs are processed by the X-Force Protection System (XPS) and reviewed by SOC analysts to ensure that security incidents were not missed.

IBM Security – Managed Security Services Client Enablement

Viewing Last Log Received Information

You can view the timestamp of the last log received on the Device Manager page in the VSOC Portal. To access this information, from the Devices menu, select Device Manager. The time of the last log received is displayed in the Newest Log column.

The Newest Log Column includes both IDS/IPS Events and System Status Events. If your IDS/IPS is only sending system events, it may show recent logs but still have an open NLR ticket for the investigation of a lack of IDS/IPS events.

Log Management Services

For the Log Management Service (SELMS/LMS), MSS uses an approach similar to the one described above. However, please note that the tickets have the ticket type “No Logs Received (SELMS)” and go straight to the VSOC Portal.

Important: Initial troubleshooting of these tickets is the responsibility of the client technical contacts, as the SOC has no access to these unmanaged devices. If the problem is determined to be with the SOC infrastructure, or if the device threshold needs adjustment, please contact the SOC.

IBM Security – Managed Security Services Client Enablement

Baseline Device Policy Best Practices

The Baseline Device Policy area of IBM Managed Security Services Best Practices focuses on ensuring that baseline policies for both IBM and third-party devices are configured and managed effectively.

Unless otherwise requested, IBM deploys new IDS/IPS devices and agents with a standard baseline policy developed by the IBM Security Operations Center (SOC). IBM baseline policies generally reflect the default policy recommendations of the respective product vendors. This includes which signatures are enabled, and which responses, for example allowing or blocking traffic, are configured for each signature. However, based on trends and emerging threats detected by IBM security analysts, baseline policies may include deviations from vendor recommendations.

Migrating Policies for Existing Devices and Agents

If you migrated existing IDS/IPS devices and agents to IBM from other vendors, your policies may have undergone comprehensive tuning prior to the migration. In such cases, clients often request that existing policies be migrated intact to preserve that tuning. However, you should consider whether these policies could also preserve security holes related to prior misconfiguration. If little tuning was performed, or the tuning is outdated or ineffective, then IBM recommends replacing existing policies with IBM default policies. In addition, if any of your devices are configured to block, configuring the devices to run in non- blocking, "learning" mode is advisable prior to deploying policy changes to production.

Policy Sharing

For clients who have multiple IDS/IPS devices and agents of the same model or version (and operating system for HIDS), IBM shares policies wherever possible. Shared policies:

• Provide consistency in security coverage • Allow for faster deployment of new signatures and other policy changes • Facilitate efficient auditing

Because the majority of tuning can be performed on shared policies, individual device and agent policies are generally not needed. © Copyright IBM Corporation 2010, 2020 MSS Best Practices Guide Page 16 of 82

IBM Security – Managed Security Services Client Enablement

IBM Product Policies

Default policies for IBM products closely mirror the X-Force default policy recommendations. Signature updates for IBM IDS/IPS products come in the form of X-Press Updates (XPUs). The standard XPU release process follows Microsoft’s Patch Tuesday, usually within 24 hours of the Microsoft update. X- Force also releases emergency XPUs as needed.

Getting Information on IBM Product Updates

If you need to determine if policy coverage exists for a specific vulnerability, first locate the Common Vulnerabilities and Exposures (CVE) or vendor-specific identifier for the vulnerability. You can obtain this from the program vendor or from the CVE website (http://cve.mitre.org/). To determine signature coverage for IBM IDPS products, you can then enter the CVE number into the IBM X-Force Exchange search engine. Most other IDPS vendors have similar search tools. Alternatively, you can submit this information to the SOC using a Portal ticket to determine if signatures exist for the vulnerability.

IBM Security – Managed Security Services Client Enablement

VSOC Portal Reports Best Practices

The Virtual SOC Reports area of IBM Managed Security Services Best Practices focuses on helping you identify, configure, and run the reports that are critical to monitoring and managing the security of your network.

Report Dashboard

The Report Dashboard includes several industry standard report templates that you can customize by device, device group, or time to match your requirements. MSS reports can help facilitate day-to-day security operations, including research, vulnerability assessment, threat mitigation, and workload prioritization. These reports also can help address delegation and audit compliancy requirements.

Note: You can view report data directly in the Portal. You also can export it to a CSV or PDF file for future reference, or to facilitate additional research, documentation, and delegation. In addition, you can save your report criteria and schedule your report to run hourly, daily, weekly, monthly, or yearly. The report delivery options allow you to e-mail reports to your security community in HTML, CSV, or PDF format.

Report Groups

To help you work more efficiently, the report templates are organized into the following groups:

• General Service Related – Provides an overview of events and incidents, and overall service performance • IDS/IPS Devices – Provides detailed event metrics and overall attack trends detected by sensors • Firewall – Provides detailed data related to network traffic, protocol usage, connections, target IPs, rule utilization, and suspicious host correlation. • Log Management – Provides system activity data associated with your SELM Service • Alerts – Provides a summary of potential security issues and corresponding counts

IBM Security – Managed Security Services Client Enablement

Reporting Recommendations

The following reports provide important information about the security status of your network environment, so it is essential that you run and review these reports on a regular basis.

Event Counts by Source IPs

Key Metrics: Source IP address, % of total event volume, Trend against previous period (previous week if run weekly)

Frequency: Weekly

Audience: Security Analyst, Security Intelligence Analyst, Manager of Information Security

Value: This report helps you determine the percent of attacks that are internal versus external. It also is useful in determining the percent of total traffic a source is generating. This information can help you identify compromised systems, or to tune your policies.

Event Counts by Event Names

Key Metrics: Event Name, % of total event volume, Trend against previous period (previous week if run weekly)

Frequency: Weekly

Audience: Security Analyst, Security Intelligence Analyst, Manager of Information Security

Value: This report helps you determine which types of attacks are most prevalent in your environment, for example, application attacks versus network attacks or scanning attacks versus malicious code attacks. It also is useful in determining the percent of total traffic of a particular event type. This information can help you identify compromised systems, or to tune your policies.

IBM Security – Managed Security Services Client Enablement

Event Counts by Sensors

Key Metrics: Sensor IP/Name, % of total event volume seen by sensor, Trend against previous period (previous week if run weekly)

Frequency: Weekly

Audience: Security Analyst, Security Intelligence Analyst, Manager of Information Security

Value: This report helps you determine where network volumes are highest, which can be useful in locating misconfigured or compromised systems in your network.

IBM Security – Managed Security Services Client Enablement

Device Outages Best Practices

The Device Outages area of IBM Managed Security Services Best Practices focuses on helping you work effectively with MSS SOC personnel to monitor and manage device outages and any related security incidents.

Remote Device Management A key component of IBM Managed Security Services is remote device management capability. The MSS remote monitoring system enables SOC personnel to conduct essential daily activities, such as troubleshooting, configuration management, log management, installation of upgrades, and overall device monitoring.

Through remote monitoring, the SOC is able to detect connectivity failures or other abnormal issues that could adversely affect your security and business operations. SOC personnel constantly monitor the availability of managed devices, and communicate immediately with the designated client contacts, if an event makes it impossible to manage a device via an in- band connection. The SOC team works with these contacts to identify the causes of the outage, and to identify whether the loss of connectivity represents a larger incident that could affect security or operations.

IBM Security – Managed Security Services Client Enablement

Outage Escalation Process

The following high-level workflow outlines the coordinated process by which MSS and the designated client contacts respond to a loss of in-band connectivity with a managed device:

IBM Security – Managed Security Services Client Enablement

SOC Initial Response

If a loss of device connectivity is detected, MSS raises an incident in the form of an “OUT – Device Down” ticket to register the event. Next, SOC personnel verify the device outage, using the ticket to document the steps they take. Verification consists of double checking the management connection status, and documenting any relevant technical details that could be useful later for incident troubleshooting.

After completing verification, if the outage is not resolved, a SOC analyst communicates with the designated client contacts (those with the role of "Device Outage Contact") to inform them of the outage. The SOC communicates with contacts in order of rank until someone is actually contacted. The ranking is used to ensure that contacts with lower rank are contacted before contacts with higher rank. In addition, the SOC prioritizes efforts to reach contacts designated for the site where the outage occurred. If unsuccessful, the SOC will attempt to reach "GLOBAL Contacts" until someone is actually contacted. In all cases, contacts will use the same ticket to document their response, including any tasks performed to bring the connection back up. client notification will occur within the time frame established in the System Monitoring SLA. Notification occurs via telephone, and follows the contact rank previously established by the client. The “OUT – Device Down” ticket, which will be available in the Portal on the Ticket Manager page, accompanies the notification.

Important: It is critical that you review your notification contacts, ranks, and paths regularly, as up-to-date information is vital for the MSS notification process to work effectively. You can manage Support Roles in the Portal. Work with the SOC as needed to make sure your contacts and roles are sufficient to address the needs of your organization and support MSS processes.

IBM Security – Managed Security Services Client Enablement

Client Initial Response

After the SOC escalates the device outage, the designated client contacts are expected to inform the SOC about the impact of the outage on network and business operations. This helps the SOC determine the proper level of severity to associate with ticket and incident handling. Client contacts also are encouraged to assist the SOC in determining the cause of the outage. Contacts can use the following checklist to guide their troubleshooting efforts:

• Is the device properly connected to the power outlet and powered on?

• Is the ISP connection working properly for other devices at the same location?

• Are there alerts for other devices (for example, routers or switches) at the same location? • Are the network cables properly connected between the device and corresponding switches or routers?

• Have there been any recent network changes that could affect device in-band connectivity?

A timely outage restore is important, even if it is a false positive (specifically, the device is up and fully operational but SSH connectivity is down). As mentioned earlier, the SOC makes use of the SSH connection to manage the device, and in the absence of fully working SSH communication, the SOC's ability to manage the device may be jeopardized, and monitoring and integrity checks are usually put on hold.

SOC Additional Response

If a device remains unreachable after initial troubleshooting, the SOC further investigates the cause. If out-of-band (OOB) connectivity is available for the device, the SOC should be able to dial into the OOB modem to verify the device is functioning properly. In some cases, OOB connectivity supports remote reboot, if the SOC Analyst should need to reboot the device as part of troubleshooting.

If OOB connectivity is not available, or if connectivity cannot be established, the SOC may require assistance from onsite personnel to facilitate troubleshooting. For example, an onsite resource may need to connect a laptop to the device via serial port, so the SOC can access the device remotely. In such cases, the SOC will need the onsite resource to provide access to the laptop via remote support, for example, RDP or VNC.

IBM Security – Managed Security Services Client Enablement

If the device becomes reachable during troubleshooting, and is detected by the remote monitoring system, the system will auto-close the outage ticket. In such cases, the ticket will be put in a Resolved, Pending Closure status. The SOC analyst also can close the ticket manually upon resolving the outage issues. If a ticket is manually closed while the device is still unreachable, a new outage ticket will be generated automatically by the monitoring system.

Additional Best Practices

Client OOB Verification

It is essential that you regularly check that your devices are connected to the OOB modem’s power outlets and ensure the telephone line connected to the OOB modem is working properly.

Important: Before contacting the SOC to request OOB connectivity testing, verify the SSH connection to the device. If you cannot SSH into the device successfully, document any relevant details for incident troubleshooting and contact the SOC.

"Non-designated" Client Contacts

There must be at least one client designated security contact working with the SOC on troubleshooting an outage. If involvement of people who are not part of the client’s designated security contacts is needed, a designated security contact must update the ticket work log with the individuals' names and contact numbers, authorizing them to work on the case. Otherwise, the SOC will not be allowed to work with the individuals.

Scheduled Maintenance: It is the client’s responsibility to notify the SOC via a general ticket about any internal maintenance scheduled to take place onsite, providing both start and end times. This allows the SOC to configure scheduled downtime in the monitoring system and prevent it from generating outage alerts for the affected devices during the maintenance period.

IBM Security – Managed Security Services Client Enablement

Common Causes of Preventable Device Outages This is a quick guide intended to educate our clients about common things that cause Severity 1 outages that may impact a client’s network and infrastructure. Many of these outages can be avoided by simply notifying the IBM MSS SOC via a ticket, that is easily created using the VSOC Portal, of any changes to your network.

Listed below are some common examples:

• ISP Changes - This often impacts devices being managed by the IBM MSS SOC and usually require IP and routing changes. Please notify the SOC of any ISP changes so we can ensure our team has the most updated and correct information concerning your network.

• IP Address Changes – Changing the IP Address on any managed device will impact the IBM MSS SOC’s ability to manage the device and effectively detect threats. Please notify the SOC of any IP address changes.

• Data center Maintenance – The IBM MSS SOC can better assist with all clients if we are notified of scheduled Datacenter Maintenance windows. Keep the SOC informed as part of your maintenance window planning.

• Power/Energy Maintenance – Always notify the IBM MSS SOC of a scheduled power/energy maintenance so we can adjust our alerts and not send unnecessary notifications.

• Network Redesign – Always notify the IBM MSS SOC during a network redesign so the SOC has the latest network information to support and protect your environment.

• Device Shutdown/Reboot – It is a recommended best practice to notify the IBM MSS SOC of a planned device shutdown or reboot so we can manage alerts and notifications as well as keep track of the health of your security devices.

• Changes to Connected/Networked Devices – Always notify the IBM MSS SOC about changes to devices connected or directly attached to the Managed Security Device to prevent false positive notifications and to ensure the SOC has the latest network information to support and protect your environment.

• Network Port/Speed Changes – Consult the IBM MSS Operations Desk about submitting a Policy Change Request (PCR) for changes on network ports or speed of any device connected to Managed Devices to prevent issues. PCRs will ensure the proper collaboration between teams to prevent unnecessary outages and ensure your Managed Devices are running at full capacity.

IBM Security – Managed Security Services Client Enablement

• Network Cabling Changes – Always inform the IBM MSS SOC of cabling changes that may generate false alerts. The SOC has health alerts that constantly look for the correct configuration of the managed devices, changing cables may temporarily generate outage and security alerts.

• Application Changes/Additions – Always notify the IBM MSS SOC of application changes or new applications that may modify traffic behavior so we can tune and adjust your traffic filters and security alerts.

These are just a few examples of common everyday changes that can impact your security environment and the IBM MSS SOC’s ability to manage the devices. It is recommended that any time you are making changes in an environment that contains a device managed by IBM MSS, that you speak with the SOC to ensure that the changes will not have a negative impact on your security posture.

IBM Security – Managed Security Services Client Enablement

Vulnerability Management Best Practices

The Vulnerability Management area of IBM Managed Security Services Best Practices focuses on helping you work effectively with MSS to ensure that you have the vulnerability data needed to support the internal and external requirements of your organization.

The Hosted Vulnerability Management Service (VMS) is a vulnerability scanning service that provides the tools required to support a range of needs, including internal audit and risk assessment, regulatory compliance, and industry compliance requirements. VMS includes a comprehensive suite of functionality, including certified Payment Card Industry (PCI) approved scanning vendor reports. The PCI Approved Scanning Vendor (ASV) service is included for IBM Enterprise VMS clients via a separate tool.

Types of VMS Scanning

IBM provides VMS as a solution to be operated by you and will provide the scanning application and technical support for the application from the services. VMS is provided in two distinct types of scanning, external and internal, which can be employed together or separately.

External Scanning - IBM hosts and manages vulnerability scanners on the Internet. These groups of scanners are known as the IBM Global Scan Pool. External scan engines detect security risk exposures open to the Internet, and thus focus on scanning your public-facing IP addresses and web applications.

Internal Scanning - IBM also supports scanning within your enterprise network, using an IBM-managed, on-premises scanning device (called a "scan engine"). These are dedicated engines and cannot be used for any other purpose while under IBM management. They are accessible only via the VSOC Portal interface.

IBM Security – Managed Security Services Client Enablement

VMS Data Analysis and Reporting

This unified vulnerability solution scans your networks to identify assets, and probe for vulnerabilities. The vulnerability checks in VMS identify several sources of security weakness, including operating systems, databases, network protocols, and applications. VMS can even detect some malicious programs and worms, identify areas in your infrastructure that may be at risk for an attack, and with additional access, verify patch updates and security compliance measures.

VMS generates scan data for analysis directly in the Portal interface, where you also have access to customizable reports to facilitate risk assessment and asset remediation. VMS reports are available in multiple formats, and they allow you to filter scan data by vulnerability category and severity, as well as by site, asset group, or specific range and type of assets.

Additional links for further help with VMS Best Practices:

VMS Contract Page: https://www.ibm.com/services Qualys Best Practices: https://discussions.qualys.com/docs/DOC-3814

IBM Security – Managed Security Services Client Enablement

Ongoing Operations

The Ongoing Operations area of MSS Best Practices focuses on activities that occur on a regular basis as you use MSS services in your daily business operations.

IBM X-Force Command Centers

IBM X-Force Command Centers bring you best-in-class security technology, tactics and expertise. IBM's global network of interlinked Security Operation Centers (SOCs) serves as the principal delivery arm for its Managed Security Services. Each of the SOCs is located within a hardened IBM facility that provides industry standard security protocols for both physical and logical security.

IBM SOCs carry SAS-70 type II certifications and are operated according to governance standards such as ISO, FFIEC, and IBM’s own ITCS104. Analysts within the SOCs leverage a set of proprietary web- based tools to access IBM’s central MSS infrastructure. They provide support to all clients, leveraging a common set of processes and procedures that remain uniform across all facilities.

IBM SOCs work on a modified follow-the-sun approach, with some facilities open 24x7, and other facilities open only during local business hours. This approach ensures that senior level security experts are on shift at all times, and it dramatically improves retention rates of IBM's skilled security resources.

IBM’s Managed Security Services are typically delivered in English, but 24x7 support is also available in Spanish and Portuguese. Toll-free support numbers are available for over 30 different countries, and calls are routed to the most appropriate SOC, based on caller location and analyst availability. Because support issues are fully documented and accessible by client Portal users, any available SOC analyst or engineer can generally provide assistance.

IBM Security – Managed Security Services Client Enablement

Device Tuning Best Practices

The Device Tuning area of IBM Managed Security Services Best Practices focuses on helping you understand the benefits associated with tuning standard baseline security policies to suit your network environment and align with your overall security policy.

IDPS Policy Tuning

Intrusion Detection/Prevention System (IDPS) policy tuning refers to the process of adapting IDPS policy to suit the network environment it is monitoring. As discussed in the Baseline Device Policy best practices. MSS initially configures IDPS devices with a standard baseline policy and then adjusts the policy as needed.

There are three general phases to policy tuning:

• Phase 1: Establish and review baseline security data • Phase 2: Configure and deploy custom policies • Phase 3: Establish policy maintenance process

Phase 1: The first phase of the policy tuning process involves gathering and reviewing baseline IDPS event data for your network, using MSS standard baseline device policies. A period of two to four weeks is typically needed to establish a good baseline. You then should perform a thorough review of this data to identify opportunities to streamline your policies to better align them with your network traffic. This effort can help:

• Reduce false positives. • Reduce the amount of data analysis required to monitor your network. • Focus incident response activities on real events.

Note: The policy review process can take from a few days to several weeks to complete, depending on the complexity and volume of events reported by the IDPS devices. However, most organizations will see real benefits from the initial policy review and subsequent policy customizations. Consequently, MSS recommends that you submit a ticket to the Security Operation Center (SOC), requesting a policy tuning session.

Phase 2: The second phase of the policy tuning process involves working with SOC personnel to actually configure and deploy your custom policies. This entails the use of Policy Change Request (PCR) tickets, which serve to track your policy changes and ensure they are implemented appropriately. Refer to the Policy Change Request Best Practices to learn more about the PCR process.

IBM Security – Managed Security Services Client Enablement

Note: An IDPS policy often contains thousands of signatures, so a review of each signature is usually impractical. If a signature is enabled and not producing false positives, you can leave it enabled. As stated earlier, the focus of your efforts should be on tuning false alarms and aligning policy coverage with your network traffic patterns.

Phase 3: Following the completion of tuning, the policy change process enters a maintenance phase, where tuning is handled on a case-by-case basis. New tuning opportunities may arise from the release of new signatures, changes in your network environment or compliance requirements, or as a result of security incident investigations.

False Alarms

A “false alarm” refers to an IDPS event that is either not a security risk, or is a risk deemed acceptable because of other factors, such as cost or availability. The term “false positive” is often used interchangeably with false alarm, but a false positive refers specifically to the case where a signature is flawed and identifies normal network traffic as an attack. (Conversely, a “false negative” refers to cases where a signature fails to detect a real attack).

It is important to identify and filter out any false alarms that trigger on a regular basis, as they are essentially "noise" in the IDPS data set that makes it more difficult to identify real attacks. Reducing the size of the data set through filtering also reduces the time lost when the incident response team investigates such false alarms. To the extent possible, incident response resources should focus on unique events that are unusual in the context of baseline network activity and traffic.

Example: No Risk Scenario

An example of a false alarm that poses no risk is an e-mail attack alert for a Microsoft Exchange vulnerability, where the target server is actually running Lotus Domino. This event can be safely ignored (filtered). If Microsoft Exchange is not used anywhere on the network, then the signature itself can be disabled, thereby eliminating future false alarms.

Example: Acceptable Risk Scenario

An example of a false alarm that poses an acceptable risk is a vulnerability scan event triggered on traffic from an in-house application that is permitted to test externally facing critical servers as a business task. In this case, the IDPS detects a series of real vulnerability scan events. However, the events pose little risk, because the scan is authorized. To resolve this issue, you could create a filter to have the IDPS ignore events from specific authorized scanners. Alternatively, you could add the scanner IP addresses to the "authorized scanners list," which would cause the XPS system to ignore the associated traffic.

IBM Security – Managed Security Services Client Enablement

It is important to define filters as narrowly as possible, configuring options to focus on specific signatures, ports, and IP addresses. The filter should be as specific as possible to eliminate the particular event from the IDPS data stream, while still allowing other events to be detected. If you need assistance identifying the best approach to create an appropriate filter, contact the SOC to discuss your scenario and requirements prior to submitting a Policy Change Request (PCR).

Using the Policy Analyzer

The Policy Analyzer, which is available from the Devices menu, enables you to view and compare policy configuration across your security devices. This helps you work more effectively with staff in the SOC to facilitate policy changes. Policy Analyzer supports several platforms, including:

• IBM GX IPS, and XGS next generation IPS • Cisco IDS IPS • Cisco, Juniper, and Check Point firewalls

Note: If the policy is unavailable in the VSOC Portal, open a ticket and request the current policy. The SOC will then upload the requested policy within the ticket.

The Policy Analyzer displays common information for policy signatures and rules, including machine host name, client device name, if available, policy type, status, and action. Depending on the device and policy type, Policy Analyzer also displays information regarding source and destination IP addresses, service, rule number, event name, severity, pattern, URL, and notification. Use the Policy Analyzer filters to focus on particular device policies and specific signatures or rules.

Verifying Coverage for a Specific Vulnerability

To determine if policy coverage exists for a specific vulnerability, first locate the Common Vulnerabilities and Exposures (CVE) or vendor-specific identifier for the vulnerability. You can obtain this from the program vendor or from the CVE website (http://cve.mitre.org/). To determine signature coverage for IBM IDPS products, you can then enter the CVE number into the IBM X-Force Exchange (https://exchange.xforce.ibmcloud.com/) search engine. Most other IDPS vendors have similar search tools. Alternatively, you can submit this information to the SOC using a Portal ticket to determine if signatures exist for the vulnerability.

IBM Security – Managed Security Services Client Enablement

Device Updates and Service Changes Best Practices

The Device Updates and Service Changes area of IBM Managed Security Services Best Practices focuses on helping you understand the types of updates and service changes available, and the best approach for implementing them in your environment.

Device-related changes fall into three categories:

• Security Content updates • Firmware updates • Service changes

Security Content Updates

Security content updates typically contain new signature information and minor updates to the device. They do not include changes to the device operating system, or to hardware drivers. Consequently, content updates generally do not impact the monitored networks, or require a maintenance window.

The Security Operations Center (SOC) applies content updates automatically unless clients specify otherwise through the exception process.

IBM Security – Managed Security Services Client Enablement

The update process starts within a specific number of hours from the official release timestamp, as outlined by the Service Level Agreement (SLA).

This SLA information is included in the appropriate service description document, which is available from the IBM Contracts page (https://www.ibm.com/support/customer/csol/terms/).

Important: Access to security content updates is typically tied to a maintenance contract with the device vendor. IBM Managed Security Services does not manage device maintenance contracts, so it is critical that you work with your device vendor, or IBM Support in the case of IBM devices, to ensure continued access to security content updates.

Content Update Release Schedules

Content updates are released on a schedule determined by each individual product vendor. For IBM security products, there is a regular monthly X-Press Update (XPU) release immediately following Microsoft’s monthly patch release. IBM also releases emergency XPUs as needed to address zero-day exploits and other urgent security issues.

IBM MSS recommends that you subscribe to the appropriate vendor email list to receive notification of new updates. For IBM security products, the IBM Security Connect newsletter provides important information related to new XPUs. You can find subscription information at the following URL: https://www-148.ibm.com/bin/subscriptions/walk_small_steps.cgi?cl=USEN&nid=10944

Firmware Updates and Security Advisories

For firmware updates, the SOC reviews each release as it is announced by the respective vendor to determine the criticality of the update. If the firmware release addresses a significant security vulnerability in the product, the SOC opens a client notification ticket with specific details and works with the designated client contacts to schedule a maintenance window to perform the update.

The SOC also opens a client notification ticket for all relevant security advisories, providing the client with vendor information about vulnerabilities and the affected products and versions. The SOC assigns the ticket to the designated client contacts and works with them as needed to answer questions and help them understand the potential impact to their organization's security.

IBM Security – Managed Security Services Client Enablement

If a client determines there is a need for a device update, the client contacts should use the notification ticket to communicate with the SOC to request the update. The SOC then works with the client to schedule a maintenance window to perform the update.

Important: IBM MSS processes require acknowledgement, planning, and coordination between the SOC and the appropriate client security contacts prior to performing updates/upgrades. IBM MSS will not perform updates/upgrades without adequate planning and coordination.

Service Change Process

IBM understands the need for flexibility in supporting clients’ evolving security needs. To accommodate your network changes, there may be times when you need to make changes to an IBM service. Before you request a service change, please review the different types of services changes below, and the Service Change Requests section at the end of this document.

Types of Service Changes

There are several types of service changes that IBM can process for clients on an as needed basis. Use the following definitions to determine which service change to request. If you have any questions regarding these service change types, please contact the SOC for clarification.

Important: Monthly service fees will continue during service changes unless your contract ends or you request a service disconnect.

• Relocation – Refers to moving a service from one location to another.

Categories of Relocation:

Network Based Service Relocation – Refers to a network service that is moved from one location to another, without a service type change or reinstallation of software. If changes other than IP address are needed during the network service move, please reference the Redeployment definition.

Host Based Service Relocation – Refers to a host service that is suspended temporarily while the service is moved to another location. Notifications from the SOC will cease until the client notifies the SOC via ticket that the service has been turned back up.

IBM Security – Managed Security Services Client Enablement

Integration - (Deployment) team engagement is required to QA the relocated service to ensure that the service is reporting as expected. This type of relocation applies to IBM server products.

SELM Service Based Relocation – Refers to uninstalling the Universal Logging Agent (ULA) on one host and installing the ULA on another host. For SELM network, the SOC's receipt of logs changes to a different device. In these situations, the client is responsible for the required actions associated with the installations and log origination. Also, you must notify the SOC of your intentions via ticket to ensure the SOC is aware of the changes, and that internal records accurately reflect these changes. The old server/network device record will be set to inactive by the SOC.

• Redeployment – Refers to a temporary suspension of service while a network device is being moved. This type of change requires involvement by the Deployment team, and you may incur additional redeployment fees. If you choose this option, your Account Manager will talk with you about these fees.

• Disconnect – Refers to turning down a device permanently, with no intention of replacing it or turning it up in another location. A Disconnect of services may be subject to termination fees. Please reference your contract for details.

Service Change Requests

To avoid errors and delays regarding service changes, it is critical that clients communicate service change requests clearly, and that all required information is provided and maintained within client records. If you need to relocate, redeploy, or disconnect a service, please complete the Service Change Request Form and submit the completed form file via Portal ticket, using the "Other Service Request" option from the Portal Ticket Menu. This will ensure that IBM has the information required to act on your request in an effective and timely manner.

Important: If you currently have a contract with IBM, you will be contacted by IBM regarding cancellation requests. Cancellation fees may apply. Please direct contract and contract termination inquiries to your Account Manager or Sales Representative.

IBM Security – Managed Security Services Client Enablement

Unmanaged Assets Best Practices

The Unmanaged Assets area of IBM Managed Security Services Best Practices focuses on helping you use the Asset Center tool to manage security information for critical assets that are not managed through IBM Security Services.

Asset Center Overview

The Asset Center is a VSOC Portal tool that facilitates management of information about critical assets that are not managed through IBM Security Services. This tool provides a way to upload critical information that can be used in the correlation and reporting capabilities of the X-Force Protection System (XPS). Using the Asset Center, you can upload or manually enter critical server and device information, as well as perform bulk uploads of asset details and third-party vulnerability scan results. After logging into the Portal, you can access the Asset Center from the “Devices” menu, illustrated below.

IBM Security – Managed Security Services Client Enablement

Adding, Editing, Importing, and Exporting Asset Information

The Asset Center provides options to add and edit information for individual assets, or to bulk upload information for multiple assets, as shown below.

Adding and Editing Information for Individual Assets - You can manually add/edit several categories of asset information, including:

• Asset Identities (for example, IP and MAC addresses, host name) • Asset Operational Details (for example, OS, ports, and applications) • Asset Groups (site, business unit, and business process) • Asset Loss Factors (for example, criticality and sensitivity)

Importing and Exporting Information for Multiple Assets - You can bulk upload asset information using a CSV file. The Asset Center provides a pre-formatted, template CSV file that accommodates the above- referenced categories of asset information. You also can export asset information to a CSV file.

IBM Security – Managed Security Services Client Enablement

Importing Third-Party Vulnerability Scan Information

The addition of third-party vulnerability scan data to the Asset Center provides a unique opportunity to reduce false alarms and streamline remediation. Vulnerability scan results, and critical asset and server information, are integrated into the Automated Intelligence (AI) correlation engine. This facilitates automatic correlation with IDPS events and threat intelligence feeds, identifying successful attacks that target known vulnerable destinations.

Using the historical analysis and prioritization of successful attacks provided by the Attacks on Vulnerable Assets report, you can generate a prioritized list of devices to remediate, including drill-in access to the NIST CVE database and IBM proprietary tools. By using regularly scheduled reports, you gain the convenience of reviewing periodic summaries as opposed to logging into the VSOC Portal.

Increased Visibility for Critical Assets

The integration of asset details and third-party vulnerability scan results creates a more complete picture of your infrastructure. In addition to feeding real-time correlation rules, this information populates other interfaces in the VSOC Portal, increasing critical asset visibility through:

• AI Alerts • Tickets • Reports • Suspicious Host Dashboard • IP Intelligence Report

IBM Security – Managed Security Services Client Enablement

Policy Change Request Best Practices

The Policy Change Request area of IBM Managed Security Services Best Practices focuses on helping you work effectively with MSS Security Operations Center (SOC) personnel to implement security policy changes in your environment.

A Policy Change Request (PCR) is a standard service request to implement a change to a device managed by IBM Managed Security Services. You submit a PCR via the VSOC Portal in the form of a ticket. A PCR ticket is the only accepted means of requesting policy changes.

Important: Please note that one PCR equates to a request for change(s) to a single device. Consequently, if you submit a ticket containing change requests for multiple devices, the number of PCRs is equal to the number of affected devices. For example, the same firewall rule applied to three devices on the same ticket would count as three PCRs. The only exception is in the case of HA devices, which are counted as a single device.

All PCRs must be submitted or approved by an authorized contact for the specific devices associated with the ticket. After a PCR ticket is submitted, a SOC engineer checks the client contact list to ensure the submitter is authorized. If the submitter is not authorized, the SOC cannot process the ticket without approval. In such cases, an authorized contact either will have to resubmit the ticket, or update the work log of the existing ticket, stating that the requested changes are approved for deployment.

IBM Security – Managed Security Services Client Enablement

PCR Tickets

There are several options in the Portal Tickets menu to create different types of PCR tickets.

The PCR ticket contains numerous fields to help ensure the SOC has all the information required to implement the change. While not all field data is required, you should provide as much detail as possible to avoid mistakes and delays in processing the change. For large changes there is an option to attach files to provide additional explanation or clarification

IBM Security – Managed Security Services Client Enablement

Note: After you submit a PCR request, you will see the following confirmation message. If any of the conditions mentioned in the message apply to your request, please contact the SOC by phone or online chat.

Policy Change Planning

PCR requests are processed very literally, so be sure to plan your changes carefully. In some cases, there may be multiple ways to achieve the desired outcome for a PCR. If you are unsure of the best way to proceed, the SOC is available to answer questions and offer advice.

Another important consideration is the policy architecture used for your devices. For example, is there a single shared policy for all of your devices? Or are the policies segmented based on some specific criterion, such as site location or logical network location? The devices included in the PCR should match all of the devices sharing the affected policy. So if there are three devices sharing a policy, include all three devices in the PCR ticket. If you submit the PCR with only one device specified, the SOC engineer may make the change exactly as requested, inadvertently breaking the shared policy structure. As a precaution, it may be a good practice to request that the changes be applied to all devices sharing the same policy.

Policy Change Management

Depending on the environment, policy change management can be a complex process. Best practice, even for smaller networks, is to incorporate internal change control into your submittal process. This facilitates appropriate review to ensure changes meet client requirements and are approved by the appropriate owners prior to PCR submission. Proper management process can eliminate mistakes that can adversely affect your environment.

IBM Security – Managed Security Services Client Enablement

PCR Ticket Processing

When you create a PCR ticket, you must choose the implementation time for the PCR. The implementation time options may include 24 hours, 12 hours, 8 hours, 4 hours, or 2 hours, depending on the types of PCRs you have purchased from IBM. The Requested Implementation Time field in the ticket lists the available PCR types, as well as the number of each type of PCR available to you. Select the most appropriate implementation time for each PCR, reserving your 2-hour and 4-hour PCRs for your most urgent changes. If you submit a 2-hour PCR, please contact the SOC by phone or online chat to discuss your request.

The SOC evaluates each PCR request to ensure it can be completed within the implementation time frame you selected. You will be notified if implementation time changes are required. Also, unless a maintenance window is specified in the ticket, the SOC may perform the change at any time within the implementation time frame.

Note: For clients operating under legacy contract agreements, the SOC processes PCR tickets within the agreed upon time frame determined by the Service Level Agreement (SLA). Unless a maintenance window is specified in the ticket, the SOC may perform the change at any time within the established SLA. Please refer to the Service Descriptions on the IBM contracts page for specific SLA information.

Important: If a PCR ticket contains insufficient information to perform the change, the SOC will notify the requester that more information is needed. In such cases, the PCR/SLA timer is placed on hold. Please note this may increase the time required to process the change request.

When implementing policy changes on a device technology that supports "staging," the SOC analyst first makes changes to a "draft" policy. Before deploying the changes to the active device policy, a second analyst reviews the changes for accuracy and completeness. After the second analyst verifies the changes, they are applied to the active device policy. In cases where staging capability is not available, changes are made directly to the active policy, and then reviewed by a second analyst. After changes are completed, the SOC notifies the PCR ticket submitter by email.

IBM Security – Managed Security Services Client Enablement

The following diagram illustrates the PCR processing flow:

Simple PCR Flow Diagram

Authorized PCR Submission by client contact

PCR is missing PCR is validated information and/or staged by SOC

PCR is deemed an OCR and/or maintenance PCR is sent back to window change (non SLA) submitter requesting

more information PCR is validated and/or staged by SOC

PCR is verified by a senior SOC anlayst and/or pushed to device; ticket set to 'Resolved Pending Closure'

Important: If you have a critical change request with potential business impact, please contact the SOC via phone or Portal chat to discuss options for implementation. Such requests may qualify as an emergency change.

IBM Security – Managed Security Services Client Enablement

PCR Scheduling

We do not allow Scheduling via Tickets. If you need to schedule a PCR maintenance window, contact the SOC via phone or chat session at least 72 hours in advance to increase the chances of confirming your desired schedule. The SOC will confirm if an engineer is available at the requested window time. It is also important to specify both a start and end time (and the time zone), so the SOC can determine if the window is long enough to perform the change, and also to allow the SOC some flexibility in scheduling the change. For example, if you request a window of 13:00 GMT to 14:00 GMT for a simple change, the SOC could schedule the change for 14:00 GMT, if 13:00 GMT is unavailable.

For policy changes that require user acceptance testing, the recommended process is to follow the PCR Scheduling Process above, this gives the SOC time to confirm that all requirements are met to implement the changes. The Soc will proceed to stage and verify the request before the window time. At time of window an assigned engineer will join scheduled window to implement and test with Client.

PCR Monthly Limits

The number of PCRs (and PCR types) you can submit each month is limited to the monthly allocation of PCRs your organization has purchased from IBM, plus the number of unused PCRs rolled over from the previous month. If you need more PCRs than you currently have in your PCR "bank," contact your IBM seller to purchase additional PCRs.

Your Policy Change Request (PCR) allocations appear in the PCR Monitor portlet, which is available on the Home Dashboard of the VSOC Portal. To add this portlet to the Home Dashboard, click the down- arrow on the tab to which you want to add the portlet, and select the Add Portlet(s) option from the pop- up menu.

Important: PCR allocations are not tied to specific devices but are pooled across all of your devices. Thus, you can apply any PCR to any device. PCRs that you do not use in the current month are rolled over into the following month. These "rollover" PCRs have a limited life. If you do not use them in the following month, they expire. © Copyright IBM Corporation 2010, 2020 MSS Best Practices Guide Page 46 of 82

IBM Security – Managed Security Services Client Enablement

PCR Line Item Limits and Other Change Requests (OCRs)

As a standard service request, PCRs themselves are limited to a certain number of "line items" per device. IBM defines a single rule-based agent policy/configuration change as any authorized request for the addition or modification of one rule on one context, with five or fewer objects in a single request. A change request requiring the addition of six or more objects, or the manipulation of two or more rules, will be counted as two or more requests. If the request applies to changes outside of the rule-based agent policy, each submitted request will be considered a single change.

If you request too many changes on a single PCR ticket, the SOC will note this and request that you resubmit the change using multiple smaller tickets to stay within the limits. If the PCR is a complex request involving many rule changes, contexts, objectives, or NAT or VPN changes, the SOC will reclassify a PCR as an OCR (Project). The graphic below provides guidance regarding how the SOC determines whether to convert a PCR to an OCR.

In such cases, IBM suggests the client use a 24-hour PCR instead of using a 4-hour or 2-hour PCR.

IBM Security – Managed Security Services Client Enablement

Non-PCR Scheduling

Maintenance windows for planned activities not related to a PCR require more advance notice. For example, if you have a planned activity that requires engagement of a SOC analyst for real-time troubleshooting or assistance, you need to schedule the maintenance window with the SOC at least 72 hours in advance.

Maintenance window schedule confirmations are based on the availability of SOC resources. If resources are not available for the requested schedule, the SOC will provide you with alternatives. It is strongly recommended that you request windows by chat rather than through ticket work logs. This allows SOC staff to offer alternatives in real time.

Note: Resources are assigned to scheduled maintenance windows daily at the beginning of each work shift. Consequently, the name of the assigned resource will not be available until after the start of the corresponding work shift on the scheduled date.

Urgent Window Scheduling

It is important that you limit urgent schedule requests to critical issues that arise out of unforeseen circumstances. SOC staff will attempt to accommodate urgent requests for assistance, but as with all such requests, schedule confirmation is dependent on resource availability. If SOC staff cannot accommodate a request, they will provide alternatives such as call backs or alternate scheduling

Maintenance Window Cancellation

If you determine that you will not be able go forward with activities associated with a confirmed maintenance window (PCR or Non-PCR), please contact the SOC as soon as possible to cancel the maintenance window, so that the assigned SOC resource can be made available for other client activities.

IBM Security – Managed Security Services Client Enablement

Security Incident Classification and Escalation Best Practices

The Security Incident Classification and Escalation area of IBM Managed Security Services Best Practices focuses on the incident related processes performed by IBM Security Services as part of network intrusion detection and prevention system (IDPS) event monitoring.

Incident Classification and Escalation Overview

IBM Security Services is dedicated to providing clients with the highest level of protection services to help address vulnerabilities and guard against Internet-based threats. As part of those services, highly trained security personnel are constantly monitoring and evaluating real-time intrusion event data, and systematically categorizing and prioritizing each vulnerability and its corresponding threats.

As shown in the diagram below, SOC analysts inspect incoming events in real-time. Analysts quickly evaluate and prioritize these events, leveraging the assets of the IBM X-Force® Research and Development team. This process is not based solely on the vendor’s predetermined event severity. The SOC also relies heavily on the correlation of X-Force security intelligence, global threat awareness, and a client's security posture.

IBM Security – Managed Security Services Client Enablement

Security Event Data

A security event is defined as the output of a security device or application. Examples of security events include alerts from intrusion detection/prevention sensors (IDPS) or logs from firewalls.

Security devices and applications create events and populate them with data that records and defines the conditions of a potential attack or traffic connection. Event formats and specific data fields vary for different device types and vendors. However, all events contain basic security information, such as:

• Date and time of event • Sensor or device name • Event or attack name • Severity or priority • Action taken (accept, drop, block, alert) • Source IP address and port • Destination IP address and port

Incident Classification and Escalation Process

As part of initial event triage, SOC analysts draw on their in-depth knowledge of vulnerabilities and attack vectors to quickly eliminate false alarms from the client dataset. Events that cannot be immediately dismissed trigger a comprehensive review of vulnerability data, past security incidents, client network diagrams, and real-time cross-correlation of global attack trends. SOC analysts employ a five-phase methodology to thoroughly investigate anomalous or suspicious activity:

• Phase 1: Intelligence and Attack Analysis • Phase 2: Source and Target Investigation • Phase 3: Incident Classification and Prioritization • Phase 4: Incident Escalation • Phase 5: Countermeasure Recommendations

IBM Security – Managed Security Services Client Enablement

Phase 1: Intelligence and Attack Analysis

IBM X-Force intelligence provides the basis for the initial triage of events. Using information about how the exploits work, SOC analysts correlate activity patterns with signature severity to associate the behavior with known attacks. This allows the SOC analyst to determine the potential risks associated with the events.

Phase 2: Source and Target Investigations

The second phase of the IBM Security Services methodology requires the investigation of the sources and targets of the activity. This investigation varies based on whether the source and target machines are internal or external to a client’s network. For internal machines, the SOC cross-references against monitored network diagrams, critical server information, and vulnerability scan data. For external machines, analysts cross-reference against the X-Force black list IP blocks, known attackers, and past investigations and escalations.

Phase 3: Incident Classification and Prioritization

It is important to note that not all investigations of suspicious activity result in the declaration of a Security Incident (SI). Only after careful examination and analysis of the data is an event classified and prioritized.

Security Incident Categories

To help guide subsequent actions, classification occurs in the context of the following incident categories:

• SI – Malicious Code: Used to classify a virus, worm, Trojan or other code-based entity that has successfully infected or compromised an internal system and has begun propagating within internal networks or systems. • SI – Probes & Scans: Used to classify activity on a network that is indicative of reconnaissance activities intended to discover systems and facilitate network mapping. • SI – Denial of Service: Used to classify an attack that impairs the use of networks, systems, or applications by exhausting connection and bandwidth resources. Both Denial of Service (DoS) and Distributed Denial of Service (DDoS) attacks fall into this category. • SI – Unauthorized Access: Used to classify a situation where unauthorized logical access to a network, system, application, data, or other resource occurs. This incident category includes root compromises, unauthorized data alterations, and web-site defacements. © Copyright IBM Corporation 2010, 2020 MSS Best Practices Guide Page 51 of 82

IBM Security – Managed Security Services Client Enablement

• SI – Inappropriate Use: Used to classify violations of acceptable use policies. The use of peer-to- peer file sharing applications and other misuses or abuses of resources fall into this category. • SI – Trend Analysis: Used to classify anomalous activity within a standard event stream for a given device. Because trend analysis requires a historical review of an event stream, it is not typically performed in real-time. • Non-actionable Activity: Used to classify the majority of the events, which turn out to be false alarms. These events are triggered by malicious traffic in the client environment, but the targeted networks and servers are not vulnerable to the exploits. A common false alarm involves the presence of mass worm traffic on a network. Worms such as Code Red, Nimda, Slammer, and Blaster continue to propagate on the Internet and connected client networks. However, unless a client server is infected and actively propagating a worm, there is no need for action, and the event is not escalated.

• Note: Non-actionable activities are further organized into the following Commented Security Incident (CSI) categories, which are also visible within the VSOC Portal:

– Host Not Vulnerable – External Activity – Authorized Scan (per client notification) – Traffic Blocked – Acceptable Traffic

IBM Security – Managed Security Services Client Enablement

Security Incident Priority Levels

After classification, the SOC analyst prioritizes the SI by correlating three factors (as shown in the diagram below):

Security Incidents are organized into three priority levels:

Priority 1 (Magnitude 8-10 offenses): Incidents at this level are actionable, high-risk events that have the potential to cause severe damage to client environments. Priority 1 events require clients to take immediate defensive actions. System or data compromises, worm infections and propagation, massive denial of service (DOS) attacks, and similar incidents are assigned this priority level.

Priority 2 (Magnitude 5-7 offenses): This is the lowest level of actionable incidents. Priority 2 incidents require clients to take actions within 12 to 24 hours of notification by the SOC.

Incidents such as unauthorized local scanning activity, and attacks targeted at specific servers or workstations, are assigned this priority level.

Priority 3 (Magnitude 2-4 offenses): Incidents in this category involve activity on a network or server that is not directly actionable. Discovery and vulnerability scanning, information gathering scripts, and other reconnaissance probes are assigned this priority level. It is recommended that clients respond to Priority 3 incidents within 1 to 7 days of notification by the SOC.

IBM Security – Managed Security Services Client Enablement

Phase 4: Incident Escalation

In accordance with IBM Security Services Service Level Agreements (SLA), as outlined in the individual Service Descriptions, SOC analysts escalate security incidents to the previously established authorized security client contacts as noted below:

• Select Level - IBM will respond to all identified security incidents within 15 minutes of identification. The client’s designated security incident contact will be notified via e-mail or other electronic means. • Standard Level - IBM will respond to all identified security incidents within 30 minutes of identification. The client’s designated security incident contact will be notified by telephone for Priority 1 security incidents and via e-mail for Priority 2 and 3 security incidents.

Note: During a Priority 1 security incident escalation, IBM will continue attempting to reach the designated client contact until the contact is reached or all escalation contacts have been exhausted.

The IBM Security Services Contract Documents page (https://www.ibm.com/support/customer/csol/terms/) contains the most up to date Service Descriptions available, as well as the applicable SLAs for all services provided by the SOC. IBM Security Services security escalation best practices are based on the principle of actionable information. Those items that require immediate action are escalated to clients first via the most rapid method. Lower priority items are escalated to clients in accordance with the recommended time to resolve the issue.

Escalation Methods

The recommended escalation methods for each security incident classification are as follows:

Incident Classification Primary Method Secondary Method Security Incident – Priority 1 Telephone Mobile Phone Security Incident – Priority 2 Telephone or Email Mobile Phone Security Incident – Priority 3 Email Portal False Alarm None None

Note: Clients have the flexibility to configure the methods by which SOC analysts will escalate security incidents. Changes to the escalation methods per contact, as well as the actual client contacts, can be submitted through the VSOC Portal or by authenticated telephone call into the SOC.

IBM Security – Managed Security Services Client Enablement

Escalation Paths

SOC analysts use a custom escalation path to contact clients during a security incident escalation. This escalation path includes the order in which to call authorized security contacts, and the telephone numbers the SOC may use. A security incident escalation that requires immediate action triggers the telephone escalation process shown below. Starting with the primary security contact, the SOC dials through all provided telephone numbers prior to moving to the secondary contact. The process repeats for each authorized contact in the escalation path until a client contact is reached, or all contacts have been exhausted.

Note: The order of security contacts and their contact methods are customizable. Changes to the ordering of authorized contacts and the telephone numbers can be submitted through the VSOC Portal.

IBM Security – Managed Security Services Client Enablement

Phase 5: Countermeasure Recommendations

After reaching an authorized contact during a Priority 1 Security Incident escalation, the SOC analyst will recommend appropriate actions to thwart or contain the attack. The countermeasures available to the SOC and clients vary based on the services and platforms managed by IBM Security Services at the affected site. A list of countermeasures and their associated properties is detailed in the table below.

Type IBM Default Action Requires Authorization Platforms Reactive Block ** No Yes IBM IDS/IPS All Network and Host Kill ** No Yes IDS/IPS ISP Notification Yes No All Firewall Policy or ACL IBM IDS/IPS or No Yes Change Managed FW

** The Reactive Block and Kill countermeasures are required only for attacks that are not blocked by IBM Security Services SOC default policies.

The final stage of any incident escalation is documentation. All aspects of the activity and attack are documented within a Security Incident ticket and report. All ticketing and reporting information is available to clients in real-time in the VSOC Portal.

Important: Based on available data and its knowledge of the client environment, the SOC will provide as much information as possible to support the client in responding to incidents. However, it is the client’s responsibility to manage and respond to incidents, and to approve any SOC countermeasure recommendations.

IBM Security – Managed Security Services Client Enablement

Exceptions and Special Conditions

Occasionally, there are situations beyond the control of IBM Security Services or the client that will impact the SOC’s ability to respond to threats facing client resources. The two most common situations are:

• Internet Emergencies • Widespread Internet worm infections

Internet Emergencies

In the event of a widespread incident where the Internet Alert Condition exceeds AlertCon-3, or the incident adversely affects a significant portion of IBM Security Services protected networks, IBM Security Services will declare an Internet Emergency. Your authorized security contacts will be notified by email within fifteen minutes of the declaration of the emergency. This notification is designed for display on any device, including SMS capable devices such as Cellular Phones and Pagers, and will include an incident tracking number, a telephone bridge number, and the time that a situation briefing will occur.

During declared Internet Emergencies, IBM Security Services will provide regular, live telephone- conference situation briefings and summarized email briefings to provide clients with actionable information about how to protect their organizations. Regular situation briefings following the onset of an Internet Emergency supersede any requirement for IBM Security Services to provide client specific escalations for events directly related to the declared Internet Emergency. All other priority level incidents during this time will be communicated only by automated systems, such as email, pager, and voice mail.

Standard escalation practices will resume upon conclusion of the stated Internet Emergency. Termination of an emergency state is marked by a decrease in the Alert Condition to AlertCon-2, or an email notification delivered to authorized client security contacts.

Widespread Internet Worm Infections

During a widespread Internet worm infection, SOC analysts will escalate the initial infections to the client authorized security contacts. Following initial escalation, these worm infections can propagate through client networks at an exponential rate. Consequently, after the initial infection has been escalated, additional propagation within a client site is not reported. If additional sites become infected with worm activity, subsequent escalations would be warranted. During worm propagation, a current list of infected hosts is available in the VSOC Portal.

IBM Security – Managed Security Services Client Enablement

Problem Resolution

The Problem Resolution area of MSS Best Practices focuses on activities and practices related to resolving service issues. Understanding how to engage IBM resources and processes to identify and solve problems is essential to maintaining the effectiveness of the services you have engaged IBM to provide.

As with any complex technology, you may occasionally experience issues related to your IBM Security Services. IBM works hard to anticipate and prevent problems, but if an issue arises, please engage your SOC Support team for help. They will work closely with you to troubleshoot an issue, identify the underlying causes, and explore the available options and resources to resolve the problem.

IBM Security – Managed Security Services Client Enablement

Security Operations Center Escalation Best Practices

The Security Operations Center (SOC) Escalation area of IBM Managed Security Services Best Practices focuses on helping you document incident related circumstances and activities prior to communicating with the SOC.

SOC Communication Channels

The following diagram illustrates the lines of communication into the SOC, and the flow of client information within the Managed Security Services Operations teams.

IBM Security – Managed Security Services Client Enablement

Preparation for Communicating with the SOC

Prior to calling the SOC, it is important to gather information that can help the SOC analysts understand the circumstances and characteristics associated with an incident. Having this information available will ensure appropriate routing and prioritization of the issue within the SOC and facilitate the fastest possible resolution.

Incident General Information

You first should answer some general questions regarding the incident, such as:

• Is the incident still in progress? • What actions have you already taken? • Does a system IBM manage, monitor (IDS) or protect (IPS, FW) the affected service, segment, or device? • Have you recently made any changes to the affected service, segment, or device? • Would you like to get in touch with the IBM Security Services Emergency Response (ERS) team for professional investigation and recovery services? • How can IBM help? Mitigation (for example, IPS/FW Block)? Detection of the traffic? Analysis of what happened? Other actions?

Incident Details

The next step is to answer some more detailed questions regarding the incident, such as:

• Is the situation caused by a virus or a targeted attack? • What problems are occurring? • What actions were being performed on systems before the problem occurred? • Did a system compromise occur? What are the indications of a compromise? • What is the impact? For example, consider:

– Duration of the incident (start and end times) – Losses of IT production service and the affected assets and clients – Impacts on service level commitments – Unscheduled outages associated with the incident – Operations and Revenue impact – List of affected systems, workstations, and servers, including host names and addresses, and any FW or IPS devices that may be inline or may provide data

IBM Security – Managed Security Services Client Enablement

Ticket status definitions and associated behavior

• New - indicates a client just created or updated a ticket. • Assigned - indicates the ticket is assigned to the SOC, and the next course of action for the ticket is for the SOC to address. • Work in Progress - indicates the SOC is actively working the ticket. A timer is logging every minute it is being worked in this status. Further, it shows at a glance to the client and other analysts in the SOC that the ticket is actively being worked on. • Pending - indicates the ticket is pending a response from the client. The next course of action is for the client to address. The ticket will automatically go into "new" status, after the client updates this ticket. • Resolved Pending Closure - indicates the ticket/issue has been resolved. It will remain in this status for 5 days awaiting any updates from the client if necessary. If no updates occur after 5 days, the ticket will auto close and enter "closed" status. • Closed - indicates the ticket/issue has been resolved, and 5 days have elapsed since the Resolved Pending Closure status was assigned. If too much time has gone by and the issue was never updated, a new ticket is normally generated cross-referencing the closed ticket.

Contacting the Security Operations Center

Prior to calling the SOC, decide whether you want to remain on the line or receive a callback. For general security services related questions or concerns, please contact the SOC:

Phone: (USA): (877) 563-8739

International Phone: +1 (404) 236 3290 (Enter your contact ID and Pin)

Chat: VSOC Portal Chat available for new or existing tickets.

Email: [email protected]

IBM Security – Managed Security Services Client Enablement

Incident Management Best Practices

The Incident Management area of IBM Managed Security Services Best Practices focuses on helping you understand how to work effectively with the IBM MSS Incident Management team to manage and resolve incidents.

MSS Incident Management Goals and Objectives

The primary goals of the IBM MSS Incident Management team are to:

• Restore normal service operation as quickly as possible • Minimize the impact on business operations • Ensure that the best possible levels of service quality and availability are maintained

The IBM MSS Incident Management team coordinates and carries out the activities required to deliver and manage services at agreed levels, and strives to handle all incidents in a consistent, timely, and cost- effective manner. IBM MSS Incident Management core objectives are to:

• Provide faster response to incidents that are causing impact to client’s business processes • Establish clear lines of communications with the client and with any providers of service • Ensure client satisfaction with the quality of MSS support and services

IBM Security – Managed Security Services Client Enablement

MSS Incident Management Process

An “incident” is defined as an event outside of standard service operations that causes, or may cause, a reduction in service quality, or a security compromise.

In addressing incidents, MSS Incident Management team generally takes the following steps:

• Establish an Incident Management Framework • Identify and log incidents • Provide initial support • Investigate and diagnose • Resolve incident and recover service • Close incidents • Own, monitor, track and communicate incidents

Addressing Different Incident Types

The IBM MSS Incident Management team adopts separate models for handling Major Incidents versus Lower-Priority Incidents. Major incidents are handled with a different procedure that operates within shorter time frames, due to the potential business impact to client business. This procedure provides for dynamic resource allocation to facilitate a swift resolution of the incident. The following diagram outlines the considerations associated with the determination of Major Incidents.

Firmware updates and security advisories for devices

The SOC also opens a client notification ticket for all security advisories, providing the client with vendor information about vulnerabilities and the affected products and versions. The SOC assigns the ticket to the designated client contacts and works with them as needed to answer questions and help them understand the potential impact to their organization's security. If a client determines there is a need for a device update, the client contacts should use the notification ticket to communicate with the SOC to request the update. The SOC then works with the client to schedule a maintenance window to perform the update.

IBM Security – Managed Security Services Client Enablement

Important: IBM MSS will not perform updates/upgrades without adequate planning and coordination between the SOC and the appropriate client contacts.

Major Incident Impact and Aspect Qualifiers

The Lower-Priority Incident process is triggered by the initial identification or report of a service incident, either by automated systems and monitoring functions, or by client security contacts. The Major Incident process is initiated only when reported and confirmed by a client security contact. Incidents taken through the IBM MSS Major Incident process are not closed until client concurrence is reached. IBM MSS will maintain and make available documented support matrices that define where to assign incidents and what response criteria to expect.

Important: The Severity 1 incident designation applies only to issues related to existing client services, applications, devices, and network configurations. If you are planning to add new services, applications, or devices, or to make network configuration changes, please consult with the SOC well in advance of implementing your changes to understand the potential impact to your IBM security services. Then coordinate the implementation of your changes with any policy or configuration changes required by IBM to avoid security issues and prevent interruptions to your security services.

IBM Security – Managed Security Services Client Enablement

Gathering Incident Details

IBM MSS Security Operations is the point-of-contact for service, support, and requests for all IBM MSS clients. Prior to working with the SOC on incident resolution, there are several general questions you should be asking. What problems are occurring? What were you or system doing before the problem occurred? Did a system compromise occur? What are the indications of a compromise? What is the impact? The answers to more detailed questions, such as the following, also will be helpful.

• When did the incident start (date/time)? • When did the incident end (date/time – if applicable)? • Total loss of IT production service to entire client set? • Unscheduled outage of any IT component resulting in a total loss of IT service to one or more components? • An IT event that impacts one or more service level commitments? • IT event that impacts revenue or delivery schedules? • Was there a significant outage to system, network, or key application that has IT service delivery impact? • Are there affected systems, workstations, or servers? • Host names and addresses of impacted systems? • FW and IPS devices you know or think may be inline or provide data?

IBM MSS Incident Escalation

For incident escalations, clients must contact the IBM MSS Operations Team by phone or Portal chat. At any moment, client authorized security contacts can request to speak to the supervisor on duty through the same contact channels.

Important: The SOC cannot accept incident reports from anyone other than "authorized" users, as defined by your Portal Support Roles.

IBM Security – Managed Security Services Client Enablement

General Security Escalations

Prior to calling the SOC, decide whether you want to remain on the line or receive a callback. For general security services related questions or concerns, please contact the SOC:

Phone (USA): (877) 563-8739

International Phone: +1 (404) 236 3290 (Enter your contact ID and Pin)

Chat: VSOC Portal Chat available for new or existing tickets.

Email: [email protected]

Ticket Escalation

You can open a ticket in the VSOC Portal to escalate an issue. Then call or open a chat in the Portal to get in contact with an analyst to have your case escalated to appropriate Tier 2 team. To expedite your call, make sure you enter your contact id and pin when prompted. You can find this information in the portal (Under your name drop-down menu>Settings>My Profile). This ensures that your call is routed appropriately. At this point issue management begins, and internal escalation to the Shift Manager takes place, as required. If further escalation is required, please request to speak with Shift Manager directly.

Management Escalation

For management escalations, please begin by contacting the “Team Lead” first. The Team Lead works on day-to-day issues and assists with SOC operations. If you are unable to contact an MSS SOC Team Lead, please request to speak with a shift manager, and then continue to a senior manager, if needed.

Service Questions and Concerns

Questions or concerns related to service delivery, billing, SLAs, or other service offerings should be directed to the Client & Services Management Team ([email protected]), which is available Monday through Friday during normal business hours (EST).

IBM Security – Managed Security Services Client Enablement

Ticket Rating – provide feedback to the SOC

The VSOC Portal Ticket Rating tool uses a 5-star rating system that allows you to grade the SOC staff on how well they handled your Portal ticket. In addition to adding a star rating to the ticket, you can enter a comment to add more specific feedback. MSS reviews rating data regularly to determine how it can better serve clients. The Ticket Rating tool is available in the VSOC Portal Ticket Manager and within each individual ticket (see graphic below).

IBM Security – Managed Security Services Client Enablement

Root Cause Analysis

Best Practices

The Root Cause Analysis (RCA) area of IBM Managed Security Services Best Practices focuses on the use of a systematic approach to understand the underlying causes of events or incidents.

RCA Guidelines

The primary aim of Root Cause Analysis is to help everyone understand the underlying cause of an event or incident for the purpose of preventing a reoccurrence. This approach helps both clients and IBM MSS to improve the quality of their operations and services.

To achieve this aim, IBM MSS uses a formal Root Cause Analysis (RCA) process. The problem solving techniques associated with this approach typically yield knowledge and information that will help prevent the recurrence of events that can adversely impact the business of our clients.

When working with the SOC on root cause analysis of incidents, follow these general guidelines:

• Client can request a root cause analysis only after an incident, as described in the Incident Management best practice, has been resolved. • All RCA requests must be submitted within 30 days from the incident's resolution. • The IBM MSS Operations team encourages clients to assist in gathering and retaining all information related to any potential RCA requests. • All RCA requests are subject approval by the IBM MSS Operations Team, based on the results of a formal evaluation process. • After the IBM MSS Operations Team approves an RCA request, a formal process begins to identify root causes, identify and implement solutions, and produce necessary documentation for client review.

IBM Security – Managed Security Services Client Enablement

• To request an RCA, contact the IBM MSS Operations Desk by phone or Portal chat, or create a request using a SOC Trouble Ticket. Please ensure that you have the SOC ticket number associated with the incident.

RCA Process Steps

IBM MSS uses four primary steps to identify root causes and implement solutions for a problem:

1. Define the problem:

• What is the problem? • When did it occur? • Where did it occur? • What is the impact of the problem to the client?

2. Create a causal understanding of the problem:

• Identify specific causes of the problem • Validate causes with verifiable data • Show logical relationships between causes

3. Identify solutions that act on known causes of the problem:

• Eliminate known causes of the problem • Determine if solution is within the scope of IBM MSS responsibilities • Determine if solution is practical • Ensure solution does not cause any other issues

4. Implement the best solutions:

• Identify problem owner • Assign action item to owner for solution implementation • Track solution implementation and close out issue

IBM Security – Managed Security Services Client Enablement

Client Security Organization

The Client Security Organization area of IBM Managed Security Services Best Practices focuses on how your organization works with MSS and uses MSS processes and tools. In general, this focus area stresses the importance of:

• Management commitment to information security Management at all levels should actively support security within the organization with clear direction, demonstrated commitment, and explicit acknowledgement of information security responsibilities.

• Information security coordination Information security activities should be coordinated by representatives from different parts of the organization with relevant roles and job functions.

• Allocation of information security responsibilities All information security roles and responsibilities should be clearly defined.

IBM Security – Managed Security Services Client Enablement

MSS / Client Interaction Model

The following workflow illustrates the process for a typical incident.

IBM Security – Managed Security Services Client Enablement

Management Reports Best Practices

The Management Reports area of IBM Managed Security Services Best Practices focuses on helping you identify, configure, and run the reports that are critical to managing the security of your network.

Management Reporting The Report Dashboard contains several report templates that can help you monitor the health of your managed security services, and clearly articulate their value. The following reports should be run and communicated to the appropriate management levels of your organization on a regular basis:

Security Manager Overview Report

Key Metrics: Total Event Volume, number of Security Incidents, number of Commented Security Investigations

Frequency: Monthly

Audience: Manager of Information Security, Director of IT

Value: Consider downloading this report as CSV and create graphs that show trends for key security metrics.

IBM Security – Managed Security Services Client Enablement

Service Level Agreement Report

Key Metrics: Total SLA related tickets, number of SLA tickets that met SLA, Average response time for SLA bound tickets

Frequency: Monthly

Audience: Manager of Information Security, Director of IT

Value: Consider downloading this report as CSV and create graphs that show trends for key security metrics.

Service Overview Report

Key Metrics: # and type of service tickets worked, Six month trend of service tickets by type, Security incident types and criticality

Frequency: Monthly

Audience: Manager of Information Security, Director of IT

Value: Consider downloading this report as CSV and create graphs that show trends for key security metrics.

Note: For more information on reports, please reference the Reports User Guide.

IBM Security – Managed Security Services Client Enablement

Client Roles and Responsibilities Best Practices

To ensure an organization's success using IBM Managed Security Services, it is critical that the organization assign staff to the following security roles, and effectively execute on the corresponding responsibilities. How an organization staffs these roles depends on its size. For small organizations, a single person could potentially perform all of these roles. In larger organizations, each role typically requires a separate individual. In the largest enterprises, multiple individuals may be needed to perform the same role.

Security Analyst

The Security Analyst is responsible for daily interaction with the managed security service through the VSOC Portal. Key responsibilities include:

• Monitor operations, including high-level event trends and device status (NLR) daily • Review open tickets daily • Review security incidents (SIs) and commented security incidents (CSIs) daily • Document Monitored Networks, Authorized Scanners, Critical Servers and Proxy Servers • Review XFTAS • Communicate important information to next line security management as necessary

IBM Security – Managed Security Services Client Enablement

Security Intelligence Analyst

The Security Intelligence Analyst is responsible for detailed analysis of security event information, and for determining when escalations both within the client organization and to the MSS SOC are necessary. Key responsibilities include:

• Perform detailed analysis of SIs and CSIs as appropriate • Respond to SOC escalations and coordinating appropriate resources within the client organization • Review XFTAS • Analyze security information to identify key trends • Communicate important information to next line security management as necessary

Manager of Information Security

The Manager of Information Security is responsible for weekly reviews of key security reports, and for communicating critical information related to the subscribed managed security services to senior management within the client organization. Key responsibilities include:

• Coordinate client incident response team and procedures to ensure timely and effective remediation • Review device policies and initiate policy change requests (PCRs) as appropriate • Assign and approve user access to the VSOC Portal • Review weekly reports • Communicate security metrics, trends, and issues to senior management on a regular basis

Incident and Emergency Response Capability

When the IBM MSS Security Operations Center (SOC) sends a client incident escalation, it is critical that your organization have the capability to address the incident in a timely manner and communicate appropriately with all stakeholders. The absence of this capability could jeopardize critical operations and lead to potential revenue loss and damage to your public reputation.

The SOC will provide information and assistance to support your organization in responding to incidents, but it is the client's responsibility to manage and respond to incidents. Consequently, it is critical that you establish roles and responsibilities around incident and emergency response.

IBM Security – Managed Security Services Client Enablement

If you need help around incident and emergency response, IBM can provide X-Force Incident Response and Intelligence Services (IRIS) to help your organization proactively and systematically respond to critical events. Visit the links below to learn more about the IBM X-Force IRIS team. https://www.ibm.com/security/services/incident-response-services https://www.ibm.com/security/services/ibm-x-force-incident-response-and-intelligence

IBM Security – Managed Security Services Client Enablement

Support Roles Best Practices

The Support Roles area of IBM Managed Security Services Best Practices focuses on ensuring that clients have assigned Portal users to the support roles appropriate for their IBM Security Services.

Managing support roles is critical to effective communication between the SOC and clients. The Portal users assigned to these roles are the basis for an organization's security contact list, which ensures the SOC can reach an appropriate contact to escalate security events. Also, the SOC cannot accept incident reports from anyone other than "authorized" users, as defined by your Portal Support Roles. Consequently, it is essential that your organization establish a support strategy and processes for ongoing review and management of support roles.

IBM Security – Managed Security Services Client Enablement

Using the VSOC Portal to Manage Support Roles

The VSOC Portal allows you to assign a Portal user to various support roles, and directly manage your security contact list. You do not need to notify the SOC to have someone added or deleted as a security contact. The Support Roles page, which is available from Portal Settings, allows you to view, filter, add, and delete support roles for Portal users.

Note: You also can view support role assignments in a Portal user's profile.

The Support Roles page lists contacts by site, service line, role, and rank, in the Support Roles matrix. When you click the Add icon, the Create New Support Role dialog appears, allowing you to assign a Portal user to a support role and ranking (also in Communication Plan).

Security Contacts Notification Order Email Phone

Security Contact Security Contact Rank 1

Security Contact Security Contact Rank 2

Security Contact Security Contact Rank 3

Service Line and Role Options

During deployment and service initiation, the IBM team will work with your organization to set up at least two individuals from the security team as Portal administrators (primary and backup). The Portal admins can add additional Portal users and assign them to the appropriate support roles and rankings. Your Support Roles will reflect the specific managed security services your organization has engaged IBM to provide. The table below lists some of the role options available for your subscribed services.

• Add/delete/modify contact • Device Maintenance • Device Outage • Security Incident • Policy Request • Policy/Signature Change • Authorized Contact • All Roles

IBM Security – Managed Security Services Client Enablement

Important: If you have questions about the roles required to support your security services environment, please contact the SOC to discuss your needs.

Creating a PIN and Pass Phrase for Security Contacts

Some support roles require security contacts to perform actions that require additional user verification. For example, security contacts with responsibility for submitting Policy Change Request (PCR) tickets in the Portal must enter a PIN to submit a ticket. This PIN is used to validate the user's identity in the MSS systems. Portal users can create or change their PIN on the Edit Profile page, which is accessible from the user drop-down menu in the upper-right corner of the Portal.

It also is important for security contacts to establish a Pass Phrase in the Portal. This Pass Phrase is used by the Security Operations Center (SOC) to confirm the identity of security contacts when they contact the SOC by phone. Some common scenarios where authentication via Pass Phrase comes into play include: • You need to contact the SOC while on vacation or holiday and do not have access to the Portal. • Your on-call staff is remote and does not have ready access to the Portal. • You suspect an incident and need to request immediate SOC action. • You do not recall your Contact ID and PIN.

To create or change your PIN and Pass Phrase, on the Edit Profile page, click Change Password, PIN, or Pass Phrase.

IBM Security – Managed Security Services Client Enablement

SOC Fundamentals Guide

Below is a quick reference guide to provide general information surrounding communicating with the SOC and information regarding enablement.

MSS Enablement | SOC Fundamentals CONTACT THE SOC There are 3 ways to connect with the SOC

VSOC Portal Chat CALL the SOC EMAIL portal.sec.ibm.com +1 (404) 236 3290 [email protected] DECLARING PRIORITY 1 Should you find your organization in an emergency situation, you can utilize this process: 1. CREATE ticket in VSOC if possible 2. CALL the SOC: select 1-1-1 to declare emergency 3. An analyst will TRIAGE situation and assign appropriate resource EESSCCAALLAATTIIONN PPAATTHH Authorized Security Contacts will be called in the order in which they are ranked (by role) starting with a 1 ranking and continuing upward. *Escalation ends at the moment that the SOC successfully reaches a user or the end of the list Site Contact Global Contact Voicemail/Email SECURITY CONTACTS

Review, Respond, Approve

SOC Interaction is allowed for Authorized Security Contacts Only

WINDOW SCHEDULING Scheduling windows is THE BEST way to ensure available resources at the proper time Events that need to occur at a specific date and time Activity that requires onsite customer assistance Don't forget: description, date & time, and devices involved ENABLEMENT RESOURCES Where can I find helpful enablement information? VSOC Portal: Support > Education

Click the Security Shield below to access Enablement materials

IBM Security – Managed Security Services Client Enablement

Produced in the United States of America January 2020

IBM, the IBM logo and ibm.com, X-Force, Express and Express Advantage are trademarks of International Business Machines Corporation in the United States, other countries, or both. If these and other IBM trademarked terms are marked on their first occurrence in this information with a trademark symbol (® or ™), these symbols indicate U.S. registered or common law trademarks owned by IBM at the time this information was published. Such trademarks may also be registered or common law trademarks in other countries. A current list of IBM trademarks is available on the Web at “Copyright and trademark information” at ibm.com/legal/copytrade.shtml.

Other company, product or service names may be trademarks or service marks of others. References in this publication to IBM products or services do not imply that IBM intends to make them available in all countries in which IBM operates.

The customer is responsible for ensuring compliance with legal requirements. It is the customer’s sole responsibility to obtain advice of competent legal counsel as to the identification and interpretation of any relevant laws and regulatory requirements that may affect the customer’s business and any actions the reader may have to take to comply with such laws. IBM does not provide legal advice or represent or warrant that its services or products will ensure that the customer is in compliance with any law or regulation.