User s Guide. Skybox Risk Control Revision: 11

Transcription

1 User s Guide Skybox Risk Control Revision: 11

2 Copyright Skybox Security, Inc. All rights reserved. This documentation contains proprietary information belonging to Skybox Security and is provided under a license agreement containing restrictions on use and disclosure. It is also protected by international copyright law. Due to continued product development, the information contained in this document may change without notice. The information and intellectual property contained herein are confidential and remain the exclusive intellectual property of Skybox Security. If you find any problems in the documentation, please report them to us in writing. Skybox Security does not warrant that this document is error-free. No part of this publication may be reproduced, stored in a retrieval system, or transmitted in any form or by any means electronic, mechanical, photocopying, recording, or otherwise without the prior written permission of Skybox Security. Skybox, Skybox View, Skybox Security, Skybox Firewall Assurance, Skybox Network Assurance, Skybox Risk Control, Skybox Threat Manager, Skybox Change Manager, Skybox 5000/5000W/5500/6000 Appliance, are trademarks and registered trademarks of Skybox Security, Inc. Check Point, SiteManager-1, FireWall-1, Provider-1, SmartDashboard, VPN-1, and OPSEC are trademarks or registered trademarks of Check Point Software Technologies Ltd. or its affiliates. All other trademark and registered trademark products mentioned in this document are the property of their respective owners. Skybox Security, Inc. Telephone (in the U.S.): SKYBOX ( ) Telephone (outside the U.S.): Fax: Website: [email protected]

3 Contents Intended audience... 7 How this manual is organized... 7 Related documentation... 7 Technical support... 8 Overview of Skybox Risk Control... 9 Skybox View platform... 9 About Skybox Risk Control... 9 The process About the Skybox View Vulnerability Dictionary Basic architecture Part I: Security Metrics Overview of the Security Metrics feature About security metrics in Skybox View Predefined security metrics Workflow for security metrics Building the model Updating the dictionary Obtaining asset and vulnerability occurrence data Discovery Center Adding organizational hierarchy (Business Units) Analyzing security metrics Viewing security metrics information Focusing on a specific security metric Viewing security metrics information Switching between security metrics Understanding security metrics information Customizing the security metrics Initial customization Security Metric properties Additional customization Remediation Remediation workflow Continuous usage Security metrics notifications Recalculating the security metrics Skybox Risk Control version

4 Skybox Risk Control User s Guide Part II: Exposure Overview of the Exposure feature Introduction to exposure Automated IT security modeling Attack simulation and visualization Business impact analysis and risk metrics Regulation compliance Risk exposure management workflow Building the model Building the network topology Network visualization (maps) Creating and saving dedicated maps Navigating the Network Map Map Groups Validating the model Overview of validating the model Verifying completeness Model completion and validation Using model validation analyses Verifying topology Verifying access Validating the setup for attack simulation Adding Threat Origins Threat Origin types Threat Origin Categories Defining Threat Origins Disabling and enabling Threat Origins Adding Business Asset Groups Defining a Business Asset Group Business Impacts and Regulations Adding dependency rules Explicit dependency rules Implicit dependencies Simulating attacks Understanding Skybox View risk Identifying the critical issues Workflow Reviewing the directly exposed vulnerability occurrences Reviewing the Threat Origins Reviewing the Business Asset Groups Reviewing attacks Check whether the problem is access-related Skybox Risk Control version

5 Contents Remediation Marking vulnerability occurrences as ignored Mitigating critical vulnerability occurrences Creating tickets manually Updating the model after fixing vulnerability occurrences Using the What If model to test changes Continuous risk management Overview of continuous usage Attack simulation for continuous usage Monitoring the risk status Automating tickets Tickets and workflow Model maintenance Part III: Continuous usage Using tasks for automation Task sequences Scheduling tasks and task sequences Task groups Monitoring task results Reports Security Metrics reports Risks reports FISMA/NIST and Risk Assessment reports PCI DSS reports Tickets reports Vulnerability Management reports Vulnerabilities reports Exporting data to CSV files Exporting vulnerability occurrence data to Qualys format Model maintenance Updating the model General maintenance Part IV: Advanced topics Advanced modeling scenarios Modeling VPNs Modeling L2 networks Overlapping networks Virtual routers Virtual firewalls Clusters Modeling multi-homed assets Merging data Using clouds as Threat Origins Advanced dependency rules Skybox Risk Control version

6 Skybox Risk Control User s Guide Additional information about exposure About attack simulation About risk Skybox View analyses Viewing risk PCI DSS support in Skybox Risk Control Access Analyzer Creating new queries Access Analyzer output Adjusting the security metrics parameters Calculation of scores for Vulnerability Level Indicator security metrics Calculation of scores for Remediation Latency Indicator security metrics Impact levels Additional security metrics parameters Vulnerability Dictionary Vulnerability Dictionary information CVE compliance IPS support in Skybox View IPS dictionary Working with IPS in Skybox View Optimization Performance considerations Optimizing Access Analyzer analysis Part V - Planning deployment Planning deployment Deployment plan Deployment team Preparing data for Skybox View Information requirements Preparing a list of network devices Defining the collection strategy Preparing scanning information Preparing the data Phases of deployment First phase Worksheets for planning deployment Deployment overview worksheet Device mapping worksheet Network scans worksheet Business Asset Group mapping worksheet Index Skybox Risk Control version

7 Preface Intended audience The Skybox Risk Control User s Guide explains how to work with Skybox Risk Control. Use this document in conjunction with: Skybox View Installation and Administration Guide, which explains Skybox View installation, and various configuration and maintenance tasks Skybox Risk Control Getting Started Guide, which explains how to use the various features of Skybox Risk Control using predefined data The intended audience is any user of Skybox Risk Control. How this manual is organized This manual includes the following parts: Overview (on page 9) Security Metrics feature (on page 12) Exposure feature (on page 44) Continuous usage (on page 111) Advanced topics (on page 129) Planning deployment (see page 201) Related documentation The following documentation is available for Skybox Risk Control: Skybox Risk Control Getting Started Guide Other Skybox View documentation includes: Skybox View Installation and Administration Guide Skybox View Reference Guide Skybox View Developer s Guide Skybox View Release Notes Skybox Change Manager User s Guide Skybox Threat Manager User s Guide The entire documentation set (in PDF format) is available in the <Skybox_View_Home>/docs directory. A comprehensive Help file can be accessed from any location in the Skybox View Manager by using the Help menu or by pressing F1. Skybox Risk Control version

8 Skybox Risk Control User s Guide Technical support You can contact Skybox Security technical support by: Calling SKYBOX ( ) inside the U.S. or outside the U.S. Using the Skybox Security support portal at You must register to use the support portal. Registered users can view the knowledge base, download updates, and submit cases. Faxing (U.S. number) Sending an to [email protected] When opening a case, you need the following information: Your contact information (telephone number and address) Skybox View version and build numbers Platform (Windows or Linux) Problem description Any documentation or relevant logs You can compress logs before attaching them by using the Pack Logs tool (see Packing log files for technical support, in the Skybox View Installation and Administration Guide). Skybox Risk Control version

9 Chapter 1 Overview of Skybox Risk Control This chapter is an overview of Skybox Risk Control. In this chapter Skybox View platform... 9 About Skybox Risk Control... 9 The process About the Skybox View Vulnerability Dictionary Basic architecture Skybox View platform Skybox Security delivers a complete portfolio of proactive security risk management solutions that automatically find, prioritize risks, and drive remediation in a large or complex network, before an adverse event occurs. Skybox solutions provide accurate intelligence for daily security and compliance management tasks such as firewall assessments, vulnerability management, threat management, and change planning. While other solutions have limitations such as finding a limited set of risks, can only be used on an infrequent basis, or are reactive and useful only after the breach has already taken place, Skybox enables daily security risk management for the complete enterprise network on an on-going basis. Skybox identifies and prioritizes a wide variety of risks automatically so that the security team has daily risk information to eliminate the most critical risks fast, before an attack. The Skybox Security Enterprise portfolio includes: Skybox Firewall Assurance: Firewall Assessment, PCI Compliance, Firewall Ruleset Optimization Skybox Change Manager: Firewall Change Management and Workflow Skybox Network Assurance: Network Modeling, Access Compliance, Connectivity Troubleshooting Skybox Risk Control: Attack Modeling, Risk Assessment, Vulnerability Management, Patch Optimization Skybox Threat Manager: Threat Analysis, Remediation Planning, and Tracking Workflow The products share common services including modeling, simulation, analytics, reporting, and automated workflow management. About Skybox Risk Control Skybox Risk Control automatically discovers and prioritizes vulnerability occurrences, using contextaware analytics that take network topology, security controls, business assets, and threat intelligence into account. Risk Control gives those on the front line of security the tools they need to focus attention on the most critical risks first to protect customer data, intellectual property and business services. Skybox Risk Control version

10 Skybox Risk Control User s Guide Highlight features Automatically creates and continuously updates a detailed model of your network topology, network and security devices, servers, and end points Incorporates vulnerability data from third-party scanners or with Skybox Vulnerability Detector, scanless vulnerability discovery technique, leveraging product configuration repositories and patch management systems, with daily vulnerability definition content updates Simulates attack scenarios from external or internal threats, highlighting possible exploitation routes by hackers, APT, malware, and internal threats, considering all network security controls such as firewalls and intrusion prevention systems Prioritizes vulnerabilities for remediation, based on exploitability and imposed risk, indicating the most critical vulnerabilities to be fixed Streamlines risk mitigation with automated proposal of remediation alternatives, including ticket generation and workflow Calculates security and risk metrics for every business unit, and for the organization as a whole Robust reporting features include customizable reports for specific audiences such as management, auditors and IT operations Advanced what-if modeling capabilities to predict risky behavior and potential business impact of proposed network changes Integrates with Skybox Threat Manager to prioritize vital threats and updated risk alerts Note: You can use Skybox Threat Manager together with the other features of Skybox Risk Control or separately. Skybox Threat Manager is documented separately in the Skybox Threat Manager Getting Started Guide and the Skybox Threat Manager User s Guide. Comprehensive device support. View the support list at The process The overall Risk Control process is divided into two basic cycles: Import asset and vulnerability data, and then generate security metrics for different technologies and different business units If desired, import network devices to get the topology, and then analyze the exposure of the network to potential attackers Security Metrics Cycle 1 Collect vulnerability occurrences (which also provides information on assets) 2 Organize the assets into Business Units 3 Look at the Discovery Center to understand the security of your inventory 4 Look at the security metrics and the analysis of top problems, such as a Business Unit with many security issues or a specific technology (e.g. Oracle Java) with security issues 5 Remediation track the pace of fixing the top issues 6 Continuous - perform the whole cycle on a regular basis to keep the organization's security status up-to-date Skybox Risk Control version

11 Exposure Cycle 1 Build the topology (bring network devices, view the map) 2 Define Threat Origins 3 Optionally define impact rules for Business Asset Groups 4 Run attack simulation 5 View the results exposure summary and details Chapter 1 Overview of Skybox Risk Control 6 Remediation check important Threat Origins (such as Internet) to see if there are directly exposed vulnerabilities that need fixing 7 Continuous - perform the whole cycle on a regular basis to minimize the organization's exposure About the Skybox View Vulnerability Dictionary The Skybox View Vulnerability Dictionary includes comprehensive and up-to-date data on network vulnerability definitions published within the world. Data source are NVD (National Vulnerability Database), published vulnerability repositories, vulnerabilities scanners, and threat management feeds. Each newly published vulnerability definition is represented in a standard format that includes a Skybox vulnerability ID (SBV ID), CVE ID (if one exists), references to scanner plugin IDs, CVSS score, description, links to relevant sources that describe the vulnerability definition, and solutions. In addition, each vulnerability definition is modeled to include exploitation preconditions and effects, which can then be used in attack simulation. The dictionary enables Skybox Risk Control to represent the vulnerability occurrences of an organization in a standard normalized way, independently of the vulnerabilities scanner or discovery method used to identify it. Skybox Risk Control then prioritizes the identified vulnerability occurrences based on information from both the dictionary and the model. The dictionary supplies the severity of the vulnerability occurrence (CVSS score), the difficulty of its exploitation, and the commonality of such exploitations. The model and attack analysis provides information on the exposure to external and internal threats, the business context, and the potential attack risk of each vulnerability occurrence. This enables the user to relate to rich and meaningful criteria for defining the SLA for remediation of vulnerability occurrences. Vulnerability occurrences with a high CVSS score, high business impact, exposure to various threats, and high attack impact (based on attack simulation), are typically classified as urgent. Basic architecture The Skybox View platform consists of a three-tiered architecture with a centralized server (Skybox View Server), data collectors (Skybox View Collectors), and a user interface (Skybox View Manager). Skybox View can be scaled easily to suit the complexity and size of any infrastructure. For additional information, see Skybox View architecture, in the Skybox View Installation and Administration Guide. Skybox Risk Control version

12 Part I: Security Metrics This part explains how to work with the security metrics feature of Skybox Risk Control.

13 Chapter 2 Overview of the Security Metrics feature You can automate the collection of vulnerability occurrence information from multiple disparate systems and calculate security metrics, which are risk indicators based on vulnerability occurrences. Security metrics provide threat indicators for your organization as a whole and for specific Business Units, enabling the security team to help management understand which threats pose the greatest risk and what your organization is doing about them. Figure 1: Security Metrics Summary page The Security Metrics feature uses vulnerability occurrence data collected on the network to calculate security metrics for each unit in your organization s hierarchy. The security metrics scores allow you to assess the current security and vulnerability status of your organization, track trends, and identify key contributors to poor performance. In this chapter About security metrics in Skybox View Predefined security metrics Workflow for security metrics About security metrics in Skybox View Skybox View uses security metrics to measure the security status of your organization. Skybox View includes predefined security metrics as well as the ability to create new security metrics and customize the existing ones. Skybox Risk Control version

14 Skybox Risk Control User s Guide Most security metrics in Skybox View measure the status of vulnerability occurrences in your organization. However, some security metrics such as MS-VLI, MS-RLI, and Cisco-RLI measure the status of applying security bulletins from vendor based catalogs. The following are the main parameters that define security metrics: Type Vulnerability Level Indicators: These security metrics measure the security status of your organization (or a part thereof) based on the status of its vulnerability occurrences or missing security updates. The more critical vulnerability occurrences or critical security updates in your organization, the higher the score. Vulnerability Level Indicators measure the average rate of vulnerability occurrences residing on assets in a group of assets, such as a Business Asset Group or a Business Unit. In simple terms, the rate is the average number of vulnerability occurrences per asset. Remediation Latency Indicators: These security metrics measure the remediation performance of your organization. The more time it takes to fix the critical vulnerability occurrences or missing security updates, the higher the score. View Remediation Latency Indicators measure the rate of overdue vulnerability occurrences: The Remediation Latency Indicator score for an asset represents the number of overdue (or relatively old) vulnerability occurrences residing on the asset, where each vulnerability occurrence is weighted. The weighting is calculated from the remediation priority of the vulnerability occurrence and its delay; high-priority vulnerability occurrences with a large delay have the highest weight. The Remediation Latency Indicator score for a group of assets (Business Asset Group or Business Unit), is the average of the Remediation Latency Indicator score of each asset in the group. Use the Remediation Latency Indicator metric to identify entities (vulnerability definitions or groups of assets) whose remediation latency is relatively high and to examine trends of remediation latency. Security View: Security View shows the status of vulnerability occurrences in your organization. Note: This is the standard view for most security metrics. Vendor Solution View: Vendor solution view shows the status of applying security bulletins from vendor-based catalogs and the prioritization of the bulletins that need to be applied. Whenever possible, results are displayed in terms of security bulletins, each of which is usually correlated to multiple vulnerability definitions. Vulnerability definitions that are not part of a security bulletins are displayed independently. Scope Vendor solution View is used by default for security metrics such as MS-VLI, MS-RLI, and Cisco-RLI, which measure the status of applying security bulletins from vendor based catalogs. The scope defines which vulnerability definitions are used in each security metric. This can include all vulnerability definitions, only vulnerability definitions or security bulletins from specific vendor-based catalogs (Microsoft, Cisco, Adobe, and/or Oracle), or a custom-defined set. You can also exclude specific groups of vulnerability definitions or products. Predefined security metrics Skybox View includes the following predefine security metrics, some of which are used to track vulnerability occurrence status and some to track remediation progress. Skybox Risk Control version

15 Chapter 2 Overview of the Security Metrics feature Security metric name Security metric long name Scope Description Vendor Solution View Adobe Bulletin Level Adobe Bulletin Level Indicator By Catalog = Adobe Security Bulletins This security metric measures the security status of your organization based on Adobe Security Bulletins. The more critical missing security bulletins, the higher the score. Cisco Remediation Latency Cisco Security Advisories Remediation Latency Indicator By Catalog = Cisco Security Advisory This security metric measures your organization s remediation performance of Cisco Security Advisories. The more time it takes you to apply the missing security advisories, the higher the score. MS Bulletin Level Microsoft Security Bulletins Vulnerability Level Indicator By Catalog = Microsoft Security Bulletins This security metric measures the security status of your organization based on Microsoft Security Bulletins. The more critical missing security bulletins, the higher the score. MS Remediation Latency Oracle Remediation Latency Overall - Remediation Latency Security View Microsoft Security Bulletins Remediation Latency Indicator Oracle Remediation Latency Indicator Remediation Latency Indicator By Catalog = Microsoft Security Bulletins By Catalog = Oracle Security Bulletins Any This security metric measures your organization s remediation performance of Microsoft Security Bulletins. The more time it takes you to apply the missing security bulletins, the higher the score. This security metric measures the security status of your organization based Oracle Security Bulletins. The more time it takes you to apply the missing security bulletins, the higher the score. This security metric measures the remediation performance of your organization. The more time it takes you to fix the critical vulnerability occurrences, the higher the score. Antivirus Integrity Vul Level Antivirus Integrity Vulnerability Level Indicator Custom = Anti-Virus Integrity This security metric measures the security status of your organization based on the alerts (vulnerability occurrences) on antivirus applications. The more unhandled critical alerts (vulnerability occurrences) you have on antivirus applications, the higher the score. Skybox Risk Control version

16 Skybox Risk Control User s Guide Mobile Vul Level Mobile Devices Alerts Vulnerability Level Indicator Custom = Mobile device Vulnerabilitie s This security metric measures the security status of your organization based on the alerts (vulnerability occurrences) on one or more of the following mobile devices: Apple Android Blackberry The more unhandled critical alerts (vulnerability occurrences) you have on mobile devices, the higher the score. New Vulnerabiliti es New Vulnerabilities (Last 30 Days) Vulnerability Level Indicator Custom = New Vulnerabilitie s last 30 days This security metric measures the security status of your organization based on the vulnerability definitions that were published in the last 30 days. The more unhandled new critical vulnerability occurrences you have, the higher the score. Overall Vul Level Vulnerability Level Indicator Any This security metric measures the security status of your organization based on its vulnerability occurrences. The more critical vulnerability occurrences you have, the higher the score. Web Browser Vulnerabiliti es Web Browser Alerts Vulnerability Level Indicator Custom = Web Browsers This security metric measures the security status of your organization based on the alerts (vulnerability occurrences) on any of the following web browsers: Internet Explorer Mozilla Firefox Google Chrome Apple Safari. The more unhandled critical alerts (vulnerability occurrences) you have on web browsers, the higher the score. Workflow for security metrics The following is the basic workflow for security metrics. 1 Analyze the security metrics (see page 29). 2 After you finish the setup, you can view the security metrics (on page 30) by organization hierarchy. 3 Make any necessary changes, such as changing the names, number of levels, or SLA periods of the security metrics (see Customizing the security metrics (on page 36)), and reanalyze. 4 In Skybox View, decide which vulnerability definitions or security bulletins to fix first and create tickets (on page 41) for them. If your organization handles the remediation process externally, export (on page 122) the relevant data to CSV. Skybox Risk Control version

17 Chapter 3 Building the model The Skybox View model (the model) is a schema in the Skybox View database that represents all or part of your organization s network; it is used for vulnerability occurrence profiling, attack simulation, risk analysis, and planning mitigation. When you have gathered as much information about your network as possible, you can begin building the model. It is recommended that you start with a relatively small first phase (for additional information, see First phase (on page 205)). Use the Model workspace and the Model tree to build the model. Note: Before collecting data from your organization s network the first time, the model must be empty. If you loaded the demo model for tutorial purposes, you must clear it (File > Models > Reset Model). In this chapter Updating the dictionary Obtaining asset and vulnerability occurrence data Discovery Center Adding organizational hierarchy (Business Units) Updating the dictionary The Skybox View Vulnerability Dictionary contains information about vulnerability definitions. When a vulnerability occurrence is found by a scanner (or by any other means), Skybox View uses the Vulnerability Dictionary to normalize the vulnerability occurrence and add all the vulnerability definition s information including its description, cross-references from various sources, and external URLs to the model. Skybox View includes the most up-to-date dictionary at the time of release, but new updates are issued periodically. If the Vulnerability Dictionary is more than a week old, update it before running vulnerability detection, calculating security metrics, or simulating attacks. To check the date and version of the Vulnerability Dictionary Select File > Dictionary > Show Dictionary Info. Update the dictionary by running the Dictionary Update Daily task. Note: This task is scheduled to run daily, but is not actually enabled to do so. To enable the Dictionary Update Daily task to run as scheduled 1 Click. 2 In the Operational Console tree, select Tasks > All Tasks. 3 In the Table pane, right-click the Dictionary Update Daily task and select Properties. 4 In the Properties dialog box, make sure that Enable Auto-launch is selected. 5 Click OK. Skybox Risk Control version

18 Skybox Risk Control User s Guide To verify that the task is running correctly 1 In the Table pane, look at the Dictionary Update Daily task. 2 If there are timestamps in the Started at and Finished at columns, the task has run successfully and you can skip the other instructions here. If there are no timestamps in the Started at and Finished at columns, the task has not run, and you must launch it manually ( ). 3 After the task is launched, check its messages. The task may fail if: The internet connection was not set correctly. There is no internet connection. In this case, you must download the dictionary and update it manually as specified in the Updating the dictionary topic in the Skybox View Installation and Administration Guide. Obtaining asset and vulnerability occurrence data Asset and vulnerability occurrence data is a necessary component of security metrics analysis and Exposure analysis. You can obtain this data from: Scanners: Organizations that use scanners on their networks can use Skybox View tasks to either read the scanned data via APIs (online collection) or import the data from files generated by the scanner. Other data sources: In many cases, areas in the network are not scanned or not scanned frequently because of deployment issues. In this case, obtain asset data from other sources, such as: Microsoft Active Directory: Skybox View can import Active Directory data to obtain your organization s Business Unit and Business Asset Group hierarchy and assets (but not asset products). Microsoft System Center Configuration Manager (SCCM): Skybox View can import SCCM data to obtain your organization s assets, products, and patches. Note: SCCM data for Microsoft technologies includes missing patches that are directly equivalent to vulnerability occurrences in Skybox View (for example: MS12-017). Other patch management and asset management systems: Skybox View can connect to these data sources (usually via ixml) and obtain information about assets, products, and sometimes missing patches for vulnerability occurrences. Import data from these other sources as often as necessary; the import is not dependent on the scheduling of specific scans. Note: Whichever sources are used, it is important to make sure that the Skybox View Vulnerability Dictionary is up-to-date (see Updating the dictionary (on page 17)) before you start. When asset data is imported from data sources that are not scanners and that do not include missing patches, it does not include any vulnerability occurrence data. Skybox View s Analysis Vulnerability Detector tasks analyze the asset data to extract vulnerability occurrences from it. For additional information, see: Retrieving scanner data (see "Retrieving the data" on page 19) Tasks, in the Skybox View Reference Guide Vulnerability detection (on page 19) For information about ixml, see the Integration part of the Skybox View Developer s Toolkit. Skybox Risk Control version

19 Retrieving the data Chapter 3 Building the model Scanner data provides information about assets and services, and information about the vulnerability occurrences that exist on scanned assets. You can add this data to the model using tasks. For information about tasks that collect scanner data and add it to the model, see Scanner tasks, in the Skybox View Reference Guide. For a sample workflow, see Workflow for importing a Qualys vulnerabilities scan (on page 20). Skybox View supports many scanners, such as Qualys QualysGuard and ncircle. A complete list of directly supported scanners is available at If your scanner is not supported, create an integration script that converts the source data to Skybox Integration XML (ixml) and import it to Skybox View. For information about ixml, see the Integration part of the Skybox View Developer s Toolkit. Patch data is an important component of the model that provides additional information about IT assets and vulnerability occurrences that is usually quite accurate and helps Skybox View to model your organization s network more accurately. You can retrieve patch data from asset management systems and patch management systems. You can use this data instead of, or in addition to, information collected from network vulnerabilities scanners. This is necessary when the vulnerabilities scanners do not cover the whole network, are not activated very often, or are not deployed at all. You can import data from asset and patch repositories as often as necessary; the import is not dependent on the scheduling of specific scans. Patch data is retrieved using collection tasks for supported patch management systems (such as Shavlik NetChk Protect), import tasks for Active Directory and SCCM, or using ixml to import patch information from other data sources (such as BigFix). For additional information about importing data from ActiveDirectory and SCCM, see Vulnerability detection (on page 19). For information about ixml, see the Integration part of the Skybox View Developer s Toolkit. Vulnerability detection Asset data is imported directly from patch management and asset management systems (such as Active Directory and SCCM) to Skybox View using tasks. After the asset data is imported, an additional task (of type Analysis Vulnerability Detector) must be run to infer the vulnerability occurrences from service banners imported as part of the asset data. Basic workflow for detecting vulnerability occurrences 1 (Optional) Import information from Active Directory to obtain your organization s hierarchy. For additional information, see Importing Microsoft Active Directory data, in the Skybox View Reference Guide. 2 View the imported Business Units, and Business Asset Groups in the Model workspace: Organization > Business Units & Asset Groups. When you select a Business Asset Group in the tree, you can see its assets in the workspace. 3 Run an Asset Management SCCM task to obtain asset information. For additional information, see Microsoft SCCM, in the Skybox View Reference Guide. 4 View the imported assets in the Model workspace: Organization > Model Analyses > New Entities > New Assets, or in any other appropriate analysis. 5 View the generated products (services) of all newly imported assets by selecting an asset and then viewing the Services tab in the Details pane. Note: You can also create operational analyses of type Services in the Model Analyses tree and, for example, set the value of the Discovery Method field to Vulnerability Detector. However, this analysis does not display the services for each asset separately. Until this point, there are assets with products, but no vulnerability occurrences. Skybox Risk Control version

20 Skybox Risk Control User s Guide 6 Run a task of type Analysis Vulnerability Detector. For information about these tasks, see Vulnerability Detector tasks, in the Skybox View Reference Guide. 7 View the generated vulnerability occurrences in any vulnerability occurrences analysis, such as Risk Control > Analytics Center > Analyses > Public Analyses > Vulnerabilities > New Vulnerability Occurrences (in the Risk Control workspace). The Discovery Method field of a vulnerability occurrence generated by this task is Vulnerability Detector. If necessary, you can display the Created Time field in the Table pane to make sure you are looking at vulnerability occurrences from the correct run of the task. Unidentified services There may be cases where an asset has services that Skybox View cannot identify based on their banner. This may occur because the banner format is new to the system or because the product is not yet supported (such as a new minor version of Windows). Sending unidentified banners to Skybox Security, as explained in the next section, can help speed up the identification. You can see these services in two places: Analyses of type Services (such as a New Services analysis). Asset analyses, in the Services tab of the Details pane, when the Show Unidentified Services check box is selected. Look at the Banner field (available as a column in Services analyses and by right-clicking the Service and selecting Properties) to see which product is involved. To send information about unidentified services to Skybox Security for identification (and inclusion in product updates) 1 Right-click the analysis that includes unidentified services and then select Export to CSV. 2 Create a ticket in Skybox View s support portal and add the CSV file as an attachment. Workflow for importing a Qualys vulnerability scan When imported into Skybox View, vulnerability scans provide information about the assets and services in your organization including their vulnerability occurrences. If the scan includes assets that are not already part of the model, they are added to the model. The following explains how to import a Qualys vulnerability scan. To import a Qualys vulnerability scan 1 In the Operational Console tree, select the Tasks node. 2 Click. 3 Type a Name for the task, such as Import Qualys Collection. Skybox Risk Control version

21 Chapter 3 Building the model 4 In the Task Type field, select Scanners Qualys Collection. 5 Fill in the Username and Password. Figure 2: Scanners - Qualys Collection task parameters 6 Define the Network Scope the locations and networks in the model to include in the task. When the collection data is imported, only data from the specified locations and network is merged with the existing model. If the network scope is empty, the entire collection is merged. 7 The Recency field defines how many days back to search for scans. To obtain the most recent scan, fill in this field according to how often scans are run. For example, if scans are run on a daily basis, 1 finds yesterday s scan. If scans are run on a weekly basis, 7 finds the most recent scan. For information about additional parameters in the task, see Qualys QualysGuard collection tasks, in the Skybox View Reference Guide. 8 Click Launch. 9 Verify that the task finished successfully: a) Select the task in the Table pane of the All Tasks node. b) Check that the value of the Exit Code is Success. If the task did not succeed, look in the Messages tab of the Details pane for information about what went wrong. This tab displays a log of the task; you can view the errors there to understand the problem. For example, a necessary file was deleted for some reason or moved to a different location. Skybox Risk Control version

22 Skybox Risk Control User s Guide 10 Close the Operational Console. 11 Check the results of the import as follows: a) Open the Risk Control workspace. b) Navigate to Analytics Center > Analyses > Public Analyses > Vulnerabilities. c) Right-click the New Vulnerability Occurrences folder and select New > Analysis. d) Type a Name for the analysis, such as Vulnerabilities imported by last Qualys scan. e) Fill in the following fields: Last Scan Time: As appropriate (Advanced tab) Discovery Method=QUALYS f) Click OK. Guidelines for setting up scanner tasks Review the following when setting up scanner tasks: Skybox View requires unrestricted scanning output output with a minimum of control devices (such as firewalls) blocking the route between the scanner and the scanned assets. Otherwise, Skybox View s analysis of access and attack scenarios in the model does not reflect the actual access and possibility of attacks in your organization. When your organization includes DHCP networks, you get a more accurate model if you use separate scans for the DHCP networks and for the static networks because Skybox View uses a different mechanism to merge scans of DHCP networks into the model. Some information found by vulnerability scanners is not needed for attack simulation. Skybox View supports blacklists, lists of scanner IDs that contain irrelevant information that Skybox View ignores. Blacklists are used when merging vulnerability occurrences into the model: scanner IDs on the blacklists are not translated into vulnerability occurrences in the model. For additional information, see Blacklists, in the Skybox View Reference Guide. Vulnerability occurrences in the model When a vulnerability occurrence is found by a scanner or by any other means, Skybox View uses the Skybox View Vulnerability Dictionary to formally model the vulnerability occurrence in the model. The following information is displayed for each vulnerability occurrence: Commonality: Unknown, Low, Medium, or High Generated by the Vulnerability Dictionary, commonality specifies how frequently attackers exploit vulnerability occurrences of this vulnerability definition. Severity: Taken from the CVSS base score, and displayed on a scale from Unknown to Critical, and as a number (0-10) Generated by the Vulnerability Dictionary. CVSS information: The Vulnerability Dictionary provides CVSS information for the base and temporal vector of each vulnerability occurrence. This standard enables users to easily analyze the impact of a vulnerability occurrence, including how can it be exploited (locally or remotely, with or without authentication, and so on) and its possible impact in terms of CIA (confidentiality, integrity, and availability). Life-cycle status: Found, Ignored, or Fixed Skybox View assigns an initial status of Found to each vulnerability occurrence detected. Later, this can be changed by Skybox View or by a user to Ignored or Fixed. Attack simulation uses only vulnerability occurrences with the Found status. Skybox Risk Control version

23 Chapter 3 Building the model When you run attack simulation, the exposure level of each vulnerability occurrence in the model is analyzed. The exposure level indicates how many steps are needed to access the vulnerability occurrence from a Threat Origin; direct exposure means that some Threat Origin can reach the vulnerability occurrence in only one step. Discovery Center The Discovery Center provides a high level view of the information Skybox View has about the model. At the top of the page, you can see: The number of vulnerability occurrences in the organization (that is, the parts of the organization are modeled) and their average age The number of vulnerability definitions The number of assets in the organization, including those which have not been scanned recently Figure 3: Discovery Center The various charts and tables below provide a high level view of the inventory of the organization, showing you how your organization looks from a Skybox View point of view. At first, this inventory enables you to see at a glance that all the information you expected is included in the model, and that, for example, you didn't miss a location or a critical network. As you continue to work with Skybox View, it also enables you to view your organization s assets from various perspectives, such as noticing how many of the assets are up-to-date and how many are overdue. Adding organizational hierarchy (Business Units) This section explains how to add Business Units and Business Asset Groups to the model. Skybox Risk Control version

24 Including information about your organization s hierarchy (Business Units and Business Asset Groups) in the Skybox View model enables Skybox View to present the inventory and findings in a logical way for your organization. You define this information after the network and security information is collected for your model. As stated in First phase (on page 205), it is recommended that you start with a first phase consisting of about five Business Asset Groups. Figure 4: Sample business hierarchy Note: When defining your organization s hierarchy, use names that match your organization. Create a naming convention that is understandable and meets the needs of your organization. This makes the first stage of definition easier, makes it easier to maintain the definitions, and makes it easier to add new ones when necessary. Business Units Business Units allow you to group your organization s Business Asset Groups into a hierarchy for management purposes. This is especially useful for large organizations. When you create analyses and reports, you can use the Business Units to organize (aggregate or filter) the results. You can also compare the risk levels of different Business Units. Defining Business Units To define a Business Unit 1 Do one of the following: In the Model tree, select the Business Units & Asset Groups node. To make the new Business Unit part of an existing Business Unit, select the parent Business Unit. 2 Right-click the node and select New > Business Unit. Figure 5: New Business Unit dialog box

25 3 Fill in the fields and click OK. Members (other Business Units and Business Asset Groups) are optional when first creating the Business Unit but you must fill them in later. Selecting an owner is optional. Managing Business Units After you create a Business Unit, you can create a hierarchy by creating Business Asset Groups or other Business Units inside the first one or by attaching existing Business Asset Groups or Business Units to the first one. You can also detach Business Asset Groups or Business Units from a parent Business Unit. To attach a Business Asset Group or a Business Unit to another Business Unit 1 In the Model tree, locate the Business Asset Group or Business Unit that is to become a part of another Business Unit. 2 Right-click the Business Asset Group or Business Unit and select Attach to Business Unit. 3 Do one of the following: Figure 6: Attach Business Units to Business Unit dialog box If the parent Business Unit exists, select it and click OK. The selected entity becomes a child node of the parent Business Unit. To make this entity part of a new Business Unit: a) Select the position in the tree where you want the new (parent) Business Unit. b) Click New. c) In the New Business Unit dialog box, fill in the relevant information. The entity that you are attaching automatically becomes a child of the new parent Business Unit, but you can also add other member entities using the Members field. d) Click OK. The new Business Unit is created in the selected position in the tree and the selected entity becomes a child node, as do any other member entities selected in step c.

26 To detach a Business Asset Group or Unit from a Business Unit 1 In the Model tree, locate the Business Asset Group or Business Unit to detach from a Business Unit. If the Business Asset Group or Business Unit is attached to more than one Business Unit, make sure that you locate the correct instance (that is, you are detaching it from the correct Business Unit). 2 Right-click the Business Asset Group or Business Unit and select Detach from Business Unit. If the Business Asset Group is no longer attached to any Business Units, it is moved to the bottom of the Business Units & Asset Groups node in the Model tree. Note: You can also attach and detach Business Asset Groups and Business Units to or from existing Business Units by dragging them to the desired locations in the Model tree. Business Asset Groups A Business Asset Group is a group of assets that serve a common business purpose. Use Business Asset Groups to model your organization according to functions provided by your IT infrastructure. To add a Business Asset Group 1 Do one of the following: In the Model tree, select the Business Units & Asset Groups node. To make the new Business Asset Group part of an existing Business Unit, select that Business Unit.

27 2 Right-click the node and select New > Business Asset Group. 3 Type a Name for the Business Asset Group. Figure 7: New Business Asset dialog box 4 Click the Browse button next to the Members field to select the members of the Business Asset Group. Select any of the following: Specific assets Networks If you select a network, every non-network-device asset currently in that network is included in the Business Asset Group. 5 (Optional) Select an Owner for this Business Asset Group. 6 Click OK. The Business Asset Group is saved. It is added in the Model tree under its parent node. For information about the parameters of Business Asset Groups, see Business Asset Groups, in the Skybox View Reference Guide. Other ways of adding organizational hierarchy information You can add new information about your organization s hierarchy to the model automatically in the following ways:

28 Import an ixml model Retrieve hierarchy information from various proprietary sources of information, such as a customized asset database. Scripts convert the proprietary information into a format (ixml) that Skybox View can import. For information about ixml, see the Integration part of the Skybox View Developer s Toolkit. Import a Skybox View model (in XML or encrypted XML format) Importing a model adds the new model s entities to the current model. In this manner, you can join several partial models representing different sections of your organization s network into a single model. Note: The imported models may also include Threat Origins.

29 Chapter 4 Analyzing security metrics Skybox View analyzes the security metrics and assigns scores based on vulnerability occurrence data of your organization s assets. Scores are assigned to each entity in the Business Units & Asset Groups tree. To analyze the security metrics With the Risk Control workspace open, select the main Security Metrics node and click. All the security metrics are analyzed. The scores of the selected security metric (by default: VLI) are displayed in the tree and additional information is shown in the workspace. Figure 8: Security Metric tree Security metrics scores may range from 0 to 100, where 0 is the best score there are no vulnerability occurrences and 100 indicates many vulnerability occurrences. For additional information about security metrics analysis, see Adjusting the security metrics parameters (on page 176). Skybox Risk Control version

30 Chapter 5 Viewing security metrics information You can view security metrics information using the Manager GUI and in reports of type Security Metrics (see page 118). The first place to view the security metrics analysis is the Analytics Center. The top half shows the highlighted security metrics in a way that you can quickly see if any of them have critical vulnerability occurrences. By default, the highlighted security metrics are the three security metrics that are the most problematic for most organizations, but you can customize this for your organization. In this chapter Figure 9: Highlighted Security Metrics Focusing on a specific security metric Viewing security metrics information Switching between security metrics Understanding security metrics information Focusing on a specific security metric After you view the overview of the highlighted security metrics, you can select a specific security metric on which to focus. To select a security metric Do one of the following: Click one of the highlighted security metrics. To select a different (non-highlighted) security metric, click at the top right of the Security Metrics section to show the entire list; drill down to the desired security metric by selecting it. The security metric that you select becomes the default security metric for display in the Security Metric tree. The Security Metric Summary page for the entire organization is displayed with the selected security metric in focus. Viewing security metrics information The Security Metrics tree includes the root node of your organization s hierarchy (named Organization by default), Business Units, and Business Asset Groups. If you want to focus on a specific Business Unit (rather than the whole organization), select that Business Unit in the tree. Skybox Risk Control version

31 Chapter 5 Viewing security metrics information The top part of the Summary tab shows the security metrics score of the selected unit, and how many vulnerable assets and contributing vulnerability occurrences or security bulletins are included in it. Vulnerable assets are those assets in the unit on which there are contributing vulnerability occurrences. (For security metrics based on vulnerability occurrences) Contributing vulnerability occurrences are vulnerability occurrences with a severity of at least the minimum severity that is used for security metrics analysis (by default, Medium). (For security metrics based on vendor security catalogs) Vendor solutions are vendor security bulletins (with a severity of at least the minimum severity that is used for security metrics analysis) that would fix vulnerability occurrences in your organization, but which have not been applied. The Security Metrics Graphs section includes: A linked contribution wheel, showing the contribution of the selected unit s subentities to the total security metrics score Click an entity in the wheel to view the Summary page for that entity. A security metrics trend graph, showing the severity of the unit s security metrics score over time The Top Subunits by Contribution table lists the subunits with the greatest contribution to the unit s security metrics score. (For security metrics based on vulnerability occurrences) The Top Vulnerability Definitions by Contribution table lists the vulnerability definitions with the greatest contribution to the unit s security metrics score (determined by the severity and the vulnerability occurrence count). (For security metrics based on vendor security catalogs) The Top Vendor Solutions by Contribution table lists the security bulletins with the greatest contribution to the unit s security metrics score. The Lowest Level Units section (for the root node and all Business Units) contains a link to a list of the Business Asset Groups of this entity, so that you can find the most critical units at the lowest level. The following additional information is also available in separate tabs: For the Organization node and Business Units High Level Subunits: Security metrics information about the direct children of the selected node (For security metrics based on vulnerability occurrences) Vulnerability Definitions: Vulnerability definitions that contribute to the security metrics score of the selected node, including their contribution to the score of the selected node (as a percentage of the total score) (For security metrics based on vendor security catalogs) Vendor Solutions: Security bulletins that contribute to the security metrics score of the selected node, including their contribution to the score of the selected node (as a percentage of the total score) Lowest Level Units: Security metrics information about the Business Asset Groups of the selected node All Security Metrics: Summary information about the selected entity for each of the other security metrics, including the number of vulnerable assets and the number of vulnerability occurrences or missing updates. For Business Asset Groups: Vulnerability Definitions or Vendor Solutions (depending on the security metric type) All Security Metrics Skybox Risk Control version

32 Skybox Risk Control User s Guide Switching between security metrics You can switch the focus to a different security metric from the Security Metrics Organization Summary page, or from the Summary page for any entity. To view information about a different security metric 1 At the top of the Summary page for any entity, next to the entity name, click to view the list of security metrics. Figure 10: Security metrics selector 2 Select the security metric that you want to view. The scores for that security metric are shown in the tree and additional information is displayed in the workspace. Understanding security metrics information Understanding the security metrics data for your organization or a specific unit involves understanding which factors contributed the most to the unit s security metrics score and then deciding how to proceed. There are several methods that you can use to understand the results: Top-down Using the top-down method, you view the security metrics scores of the main unit in which you are interested and drill down to the subunits with the highest scores, continuing in this manner until you arrive at the lowest-level units, where you can see what is triggering the high score. (In Security View) Vulnerability Definitions The Top Vulnerability Definitions table contains a list of the vulnerability definitions with the greatest contribution towards a unit s security metrics score. You can also see a list of the vulnerability definitions that contributed to the security metrics score. Drill down to the individual vulnerability occurrences to see additional information. (In Vendor Solution View) Vendor Solutions The Top Vendor Solutions table contains a list of the security bulletins with the greatest contribution towards a unit s security metrics score. You can also see a list of the security bulletins that contributed to the security metrics score. Drill down to the individual security bulletins to see additional information. Skybox Risk Control version

33 Chapter 5 Viewing security metrics information Note: For Microsoft Security Bulletins, you can also view information about bulletin supersedence. For additional information, see Superseding Bulletins (on page 33). Trends If enough information was collected to create security metrics trend graphs, you can view the trends of a specific unit to track remediation progress relative to earlier security metrics scores of that unit. Low level Using the low-level method, you look for the Business Asset Groups with the highest scores. Sometimes the criticality of a Business Asset Group is not visible from the highest levels (for example, if it contains a very small number of assets), but it should be fixed. Start by looking at the Summary tab, to try and identify factors with a high contribution to the unit s security metrics. Figure 11: Contribution to security metric score of parent unit If you lower the security metrics scores of these factors (that is, fix whatever is causing the security metric to be high), the security metrics score of the parent unit is decreased by a significant amount. If you find units with a high contribution to the security metrics score of the parent unit, you can use the top-down approach to search for the cause. Note that some units may have high security metrics scores in their own right, but not contribute significantly to the security metrics score of their parent unit. Fixing such units is usually not a first priority, as even a significant lowering of their security metrics scores does not have much impact on the security metrics score of the parent unit. If you find vulnerability definitions with a high contribution to the security metrics score, you can start the process of mitigating their vulnerability occurrences (for example, by creating tickets). Superseding Microsoft Bulletins For security metrics using Microsoft Bulletins, information about patch supersedence is available. When you select an MS bulletin, you can see which MS bulletins are completely or partially replaced by it and which newer MS bulletins (if any) replace it. An MS bulletin completely or partially replaces another bulletin if all or some patches included in the newer bulletin replace all or some of the patches included in the older bulletin. Skybox Risk Control version

34 Skybox Risk Control User s Guide Each MS bulletin shows its estimated total contribution to solving vulnerability occurrences of the selected Business Unit, which includes the direct contribution of the selected bulletin plus the direct contribution of all the bulletins it supersedes. The Superseding Bulletins tab in the Details pane shows both the bulletins that the selected bulletin supersedes and those that supersede it, including the same information about each of those as for the selected bulletin (reported date, affected assets, and more). Some bulletins that supersede the selected bulletin may be shown in a gray font. These bulletins actually supersede the selected bulletin but don t appear in the scope of the selected node. This information is provided so that you are aware of the newest relevant MS bulletins and can choose to apply them. Figure 12: Superseding Bulletins Using the top-down approach To understand what caused the score of a specific unit to be high, look at the Top Subunits by Contribution to <Security Metrics type> table. This table lists the contribution (in percentages) of each child unit to the score of the selected unit, the security metrics score, and the number of vulnerable assets. It is useful to examine these metrics in combination. For example, if a child unit contributes a large percentage to the security metrics score of its parent unit, look at the number of vulnerable assets. A high security metrics score caused by a small number of assets probably more critical than a high score caused by a large number of assets. You can view additional information about a subunit: From the table: Click a subunit in the table to move the focus (in both the tree and the workspace) to that subunit. From the High Level Subunits tab. This tab lists the immediate children (Business Units or Business Asset Groups) of the parent unit. When you select a subunit, you can view additional information about it in the Details pane. Using the low-level approach The lowest-level units are Business Asset Groups. Sometimes, instead of drilling down to find the Business Units that are contributing the most to the security metric score, it is more useful to find (and fix) the critical Business Asset Groups, which can easily be overlooked when analyzing security metrics by contribution percentages rather than by security metrics scores. Sometimes, even though a Business Asset Group does not contribute much to the overall security metrics (because it contains very few assets), the high security metrics score is an indication that this unit should be dealt with. Skybox Risk Control version

35 To view the list of lowest-level units Do one of the following: Click the link in the Lowest Level Units section Click the Lowest Level Units tab Chapter 5 Viewing security metrics information The Lowest Level Units page is displayed, with the Business Asset Groups grouped by security metrics level. Skybox Risk Control version

36 Chapter 6 Customizing the security metrics The security metrics scores are intended to provide information about the security status of your organization. Because security status is determined by your organization s policy and other factors, various factors used in displaying and calculating the security metrics scores might need to be adjusted. You can customize the predefined security metrics, and you can add additional security metrics as necessary. Each security metric is managed separately. To manage the security metrics, right-click the main node in the Security Metric tree and select Manage Security Metrics. In this chapter Initial customization Security Metric properties Additional customization Initial customization The default values for security metrics display parameters and calculation values are usually adequate as a starting point. Therefore, it is recommended that only minimal customization if any be done before the first analysis of security metrics. In some cases, it may be necessary to change one or more of the following to fit your organization s naming conventions and SLAs: The names (long and short) of the security metrics The security metric scale of some security metrics (on page 36) The SLA per severity level (on page 37) (only for Remediation Latency Indicator type security metrics) To customize a security metric 1 In the Security Metrics tree, right-click the Organization node and select Manage Security Metrics. 2 In the Manage Security Metrics dialog box, select the security metric to be customized and click Modify. 3 Make the necessary changes and click OK. The Security Metric properties (on page 37) section includes information about all the properties. Changing the security metrics scale By default, the security metrics scale includes five levels, which map the number of found vulnerability occurrences (or missing security bulletins) to a score, a named level (Critical, High, and so on), and a color scheme similar to the one used in Skybox View for risk levels. The following table lists the default values for all VLI-type security metrics, where each High-level vulnerability occurrence is worth 0.3 of a Critical-level vulnerability occurrence, and each Mediumlevel vulnerability occurrence is worth 0.03 of a Critical-level vulnerability occurrence. Skybox Risk Control version

37 Chapter 6 Customizing the security metrics Number of critical vulnerability occurrences or critical missing security bulletins VLI score Level name Color Very Low Low Medium High 6-1,000, Critical You might need to: Change the number of critical vulnerability occurrences/critical missing security bulletins Delete levels to fit your SLA Note: If you delete levels, you might also need to adjust the other information about the remaining levels according to your organization s SLAs and naming conventions. Change the level names For additional information, see Security Metric properties (on page 37). Defining the SLA per severity level For Remediation Latency Indicator security metrics, you can define the SLA time for each severity level. The SLA time defines the expected number of days for the remediation of vulnerability occurrences, based on the SLA. The following values per severity level are used by default: Critical = 30 days High = 60 days Medium = 90 days Low = None Info = None Security Metric properties Security Metric properties are relevant only when working with Skybox Risk Control. The properties and general default values of all security metrics are described in the following table. Property Description Basic Enable Highlight in summary page Short Name Long Name Specifies whether this security metric is visible to users. Specifies whether this security metric is visible in the Risk Control Summary page. Note: Up to three security metrics at a time can be highlighted in the Risk Control Summary page. An abbreviation for the name of this security metric. The Security Metric Short Name is used in the GUI and in Security Metrics reports. The full name of this security metric. The Security Metric Long Name is used in Security Metrics reports. Skybox Risk Control version

38 Skybox Risk Control User s Guide Property Description Type Scope: Any Scope: By Catalog Scope: Custom Description A description of the security metric. The general type of the security metric: Vulnerability Level Indicator: Measures the security status of your organization based on its vulnerability occurrences or on the update level of security bulletins. The more critical vulnerability occurrences or critical missing security bulletins you have, the higher the score. Remediation Latency Indicator: Measures the remediation performance of your organization. The more time it takes you to fix the critical vulnerability occurrences, the higher the score. Specifies whether the scope of the security metric is all vulnerability definitions and all catalogs of security bulletins. Determines whether the scope of this security metric is defined by one or more catalogs of security bulletins. When catalogs are used, entries are displayed as missing security bulletins. Note: The default view for By Catalog security metrics is Vendor Solution View. Enables you to define a customized set of vulnerability definitions and security bulletins as the scope of this security metric. There are several predefined sets: Anti-Virus Integrity Mobile devices Vulnerabilities New Vulnerabilities last 30 days Oracle Vulnerabilities Web Browsers To edit the existing vulnerability definition sets or define new ones, Excluded: Vulnerability Definitions Excluded: Products View Vulnerability Occurrence Age Criteria SLA per severity level click. Specifies which vulnerability definitions are excluded from the scope of this security metric. For example, if you identify a vulnerability definition that is included in one security metric and you do not want it be included in another security metric (perhaps because it relates to another technology), you can exclude it Specifies which products in the selected Product List are excluded from the scope of this security metric. Specifies the view that is used to display this security metric. Security View: Shows the security status and provides a prioritized list of vulnerability occurrences. Vendor Solution View: Shows vendor solutions and provides a prioritized list of security bulletins and vulnerability occurrences. Determines whether the age of vulnerability occurrences analyzed for this security metric type is determined by the date that they were published or by the date that they were discovered on your organization s network. The default for all security metric types is Discovery Date. Skybox Risk Control version

39 Chapter 6 Customizing the security metrics Property Critical High Medium Low Info Description Defines the SLA in days for vulnerability occurrences with Critical severity. Defines the SLA in days for vulnerability occurrences with High severity. Defines the SLA in days for vulnerability occurrences with Medium severity. Defines the SLA in days for vulnerability occurrences with Low severity. Defines the SLA in days for vulnerability occurrences with Info severity. Advanced Automatically normalize security metric levels on next security metrics analysis Note: This option is hidden by default. This option causes Skybox View to re-factor the security metrics scores so that the distribution of scores across the Business Units is according to the normal distribution. The score is adjusted according to the number of vulnerability occurrences per asset in your organization, which removes the problem of only high scores or only low scores. Note: This action is intended to create a basis for future comparison of the security metrics levels. It is only performed once per security metric. Security Metrics scale The security metric scale is divided into three to five levels. Skybox View includes default values for mapping the number of critical vulnerability occurrences per asset to a security metric score (and level), but you can change these to suit your organization. Each level includes: Value (Upper Bound): The highest number of critical vulnerability occurrences in this level Score (Upper Bound): The highest score for this level (from 0-100) Name: The name of this level Level Color: The color to represent this level in the GUI (using RGB values) The lowest level in the security metric scale. The default for all security metric types is 0.5, 20, Very Low. The second-lowest level in the security metric scale. The default for all security metric types is 2, 40, Low. The middle level in the security metric scale. The default for all security metric types is 4, 60, Medium. The second-to-highest level in the security metric scale. The default for all security metric types is 6, 80, High. The highest level in the security metric scale. The default for all Remediation Latency Indicator-type security metrics is 100,000, 100, Critical. The default for all Vulnerability Level Indicator-type security metrics is 1,000,000, 100, Critical. For the default values of each predefined security metric, see Predefined security metrics (on page 14). Skybox Risk Control version

40 Skybox Risk Control User s Guide Additional customization Because security status is determined by various parameters, you might need to make additional changes to the security metric scales. For example, the size of your organization and the number of vulnerability occurrences/missing security bulletins that is acceptable both influence the mapping. In some organizations two critical vulnerability occurrences on an asset is considered unacceptable, while in others two critical vulnerability occurrences on an asset is considered acceptable and four or five critical vulnerability occurrences on an asset is considered unacceptable. For a table of the security metrics parameters, see Security Metric properties (on page 37). For detailed information about the scale values, how the calculation is done, and advanced security metric parameters that are not configurable in the GUI, see Adjusting the Security Metrics parameters (on page 176). Skybox Risk Control version

41 Chapter 7 Remediation In this chapter Remediation workflow Remediation workflow Once you have viewed the security metrics and you understand what needs fixing, you can start the remediation process by creating tickets on either vulnerability definitions or security bulletins (such as Microsoft Security Bulletins). One or more tickets can be opened on each vulnerability definition or security bulletin, so that you can have separate tickets for the same vulnerability definition or security bulletin in different settings (such as different Business Units). To create a ticket Right-click the vulnerability definition or security bulletin in the Table pane and select Create Ticket. A vulnerability definition ticket is created. The following differences exist between tickets opened on vulnerability definitions and tickets opened on security bulletins: The Security Update tab for security bulletin tickets shows the details of the security bulletin, whereas this tab is empty for vulnerability definition tickets. The Vulnerability Definitions tab for security bulletin tickets lists all the vulnerability definitions solved by the security bulletin. The Vulnerability Definition tab for vulnerability definitions shows the details of the vulnerability definition. The scope of these tickets depends on what you selected in the Security Metrics tree when creating the ticket. So, for example, if a ticket was opened on a security bulletin when the Europe Operations Business Unit was selected in the tree, the Network Scope of the ticket includes only this Business Unit. When a ticket for a vulnerability definition or security bulletin is closed, all its related vulnerability occurrences are marked as Fixed. For additional information on the ticket workflow, see Tickets and workflow (on page 106). Skybox Risk Control version

42 Chapter 8 Continuous usage You can automate Skybox View by setting up the necessary tasks to run on a regular basis (see Using tasks for automation (on page 112)). You can set up many processes in Skybox View to run automatically, including: Model updates (on page 124) Recalculation of the security metrics scores (on page 43) Notifications of changes to security metrics scores (on page 42) Reports (documented in the Skybox View Reference Guide) General maintenance of the model (on page 127) (including saving and loading backup versions) In this chapter Security metrics notifications Recalculating the security metrics Security metrics notifications A security metrics notification is a rule that defines the conditions under which new security metrics alerts are created. For example, Notify the owner of the Corporate Services unit whenever the security metrics score of that unit becomes greater than Medium. An alert is an message that is sent when the security metrics score of a specific unit changes in a specific way. For example, if the security metrics score of a specific unit increases from High to Critical, the owner of the unit receives an alert. Alerts for security metrics events are created (based on the notifications) when Analysis Security Metrics tasks are run. Setting up security metrics notifications Admins can set up Skybox View to send alerts when security metric levels change. To create a notification 1 Select Tools > Administrative Tools > Notifications. 2 In the Skybox View Admin window, right-click the Notifications node and select New Notification. 3 In the New Notification dialog box, select the Notification Type. 4 Fill in the fields according to the table in Security metrics notification parameters, in the Skybox View Reference Guide. 5 Click OK. Alerts are triggered and sent according to your definition. Note: If necessary, you can disable notifications as necessary using the shortcut menu. Skybox Risk Control version

43 Recalculating the security metrics Chapter 8 Continuous usage Security metric scores are sensitive to changes in the model. The following actions may affect security metrics scores: Data import or collection Dictionary update Aging (running a Model Outdated task) Running a Network Scan task Running an Analysis Vulnerability Detector task User changes to the model, such as deleting, adding, or modifying vulnerability occurrences or assets You can recalculate security metrics scores manually after any of these changes or you can schedule an Analysis Security Metrics task to run as part of a task sequence after tasks that may affect the security metrics scores. As part of the security metrics analysis task, alerts can be sent to users when the security metric levels change. For additional information about tasks of this type, see Security Metrics calculation tasks, in the Skybox View Reference Guide. The RLI scores for critical vulnerability occurrences increase over time. Therefore, the RLI should be recalculated on a regular basis regardless of whether any other changes were made. You can do this manually or by scheduling an Analysis Security Metrics task to run on a regular basis, such as once a week. Skybox Risk Control version

44 Part II: Exposure This part explains how to work with the Exposure feature of Skybox Risk Control.

45 Chapter 9 Overview of the Exposure feature This chapter explains how Exposure works in Skybox View. In this chapter Introduction to exposure Automated IT security modeling Attack simulation and visualization Business impact analysis and risk metrics Regulation compliance Risk exposure management workflow Introduction to exposure Exposure is one of the main features of Skybox Risk Control and you can see overview information in the bottom half of the Risk Control Summary page. Figure 13: Analytics Center Skybox Risk Control version

46 Skybox Risk Control User s Guide The exposure-related information shown on this page includes the direct vulnerability occurrences (vulnerability occurrences that are one or two steps away from any Threat Origin) and the Threat Origins that pose the most danger to your organization. To drill down to additional information, click any of the links; or use the Exposure Summary page to view additional information including trends before drilling down. Figure 14: Exposure Summary page The page displays information about critical exposure in your organization, and you can drill down to get additional information. The information shown on this page includes the direct vulnerability occurrences (vulnerability occurrences that are one or two steps away from any Threat Origin) and the Threat Origins that pose the most danger to your organization. You can also view additional information about Threat Origin and Business Asset Groups using the tabs at the top of the Summary page. Automated IT security modeling To identify, quantify, and mitigate security exposure, Skybox Risk Control builds a model a virtual map representing the security risk profile of your organization. The model consists of: Threat profiles Network access information Vulnerability occurrence data Business Asset Group classification All four components are required to analyze business impacts completely and accurately. Skybox Risk Control employs the open collection architecture of the Skybox View platform. Information is collected by scheduling regular collection tasks that continuously supply the model with up-to-date information about changes to the network infrastructure. Skybox Risk Control version

47 Chapter 9 Overview of the Exposure feature Using Skybox View, organizations now have a single view of their security environment that is updated automatically and continuously. Subsequent attack simulation and What If analysis can now be performed safely on this model instead of on the actual networks and devices. Figure 15: The Network Map provides a picture of the model Attack simulation and visualization Skybox Risk Control conducts exhaustive, nonintrusive attack simulations against the model to measure the effectiveness of potential threats in penetrating security defenses. Using scenarios that include human attackers and malicious code, the unique Skybox View Attack Simulation Engine ascertains which assets are reachable and exploitable, and which are secure. Skybox Risk Control version

48 Skybox Risk Control User s Guide An Attack Map provides a visual, step-by-step analysis of attacks, based on simulations of possible attack paths. Skybox Risk Control graphically illustrates the multi-step path an attacker can take, identifying the specific vulnerability occurrences exploited and the network access traversed for each exploitable path. Figure 16: Attack Map This analysis allows IT departments to identify the top 2% of exploitable vulnerability occurrences that make up the primary risks to critical assets. Working from this analysis, security and IT professionals can focus on critical exposures proactively, as soon as they appear and reduce the time to remediation from weeks to hours. Business impact analysis and risk metrics Based on the results of attack simulation, Skybox Risk Control analyzes the potential business impacts on assets in terms of potential breaches in confidentiality, integrity, and availability (CIA). Attack simulation computes the likelihood of attacks. Skybox Risk Control then calculates business and compliance risks by analyzing asset values and attack probabilities. To provide the most useful analysis, you can import business-impact rules and regulation compliance classifications from asset management databases or other predefined sources. Skybox Risk Control version

49 Chapter 9 Overview of the Exposure feature Risk metrics are automatically generated for every Business Asset Group. Metrics are consolidated for individual Business Units and for the organization overall. Managers can view the results of the risk analysis in reports built on flexible report templates. Working from these reports, they can select the most effective remediation processes to reduce critical risk exposure. Regulation compliance Figure 17: Business Impacts tabbed page Security professionals can classify Business Asset Groups according to specific regulations to continuously monitor the risks facing regulated assets. Customers can choose from predefined Regulation templates, such as SOX, HIPAA, FISMA, FIPS 199/200 and NIST. Compliance officers or risk managers can also specify Regulation templates for their own industry. Using these classifications, Skybox Risk Control can analyze compliance risks and automatically generate executive and auditor reports. Risk exposure management workflow Before you can use Skybox View to manage risk exposure, you must build a model (see Building the model). Managing risk exposure consists of the following steps: 1 Simulate attacks by running a task of type Analysis Exposure, such as the Analyze - Simulate Attacks task (see Simulating attacks (on page 86)). This task simulates all scenarios for attacking your organization s network from the specified Threat Origins and uses this information to compute risk levels and possible attacks. The derived data is stored in the database. 2 Review the results of the simulation by looking at the Exposure Summary page. 3 Use the summary information and the Attack Explorer to identify the cause or causes of the most critical risk to your organization (see Identifying the critical issues (on page 87)). 4 Reduce your risk by mitigating critical vulnerability occurrences and faulty access (see Reducing your risk (on page 93)). Skybox Risk Control version

50 5 Generate reports as necessary (see Reports (on page 118)). For example, you can generate reports to: Show the current risk on all or specific parts of your organization List the vulnerability occurrences on a specific scope, with or without detailed information and suggested solutions List tickets issued for mitigation or a specific set of tickets, such as those that are open but have passed their due date Perform this process after the model is built and whenever significant updates are made to the model. Note: Risk Exposure Analysis is performed in the Exposure workspace and the Exposure tree.

51 Chapter 10 Building the model In this section, it is assumed that your organizational model already includes the following: Assets and vulnerability occurrences An organizational hierarchy (Business Units and Business Asset Groups) This section focuses on the additional information needed for Exposure. In this chapter Building the network topology Building the network topology The network topology consists of networks and the gateways that connect them. To build the network topology 1 Create and run tasks for collecting and importing data from the network devices that you defined in Preparing a list of network devices (on page 203). For information about importing device data, see Import tasks, in the Skybox View Reference Guide. For information about device-specific collection tasks, see the section relating to the task in the Tasks part of the Skybox View Reference Guide. Workflow for importing a single device (on page 51) contains a detailed workflow for importing (and validating) a single device. 2 After you run each task, check that it succeeded: a) In the Operational Console, open Tasks > All Tasks. b) In the Table pane, locate the task and check that the value of the task s Exit Code is Success. If a task did not succeed, check the Messages tab of the Details pane for information about what went wrong. 3 Create clouds (see page 53) to represent networks that are connected to the model but are not themselves modeled, such as the internet, partners, or parts of your organization s network that should not be modeled. 4 Create locations (see page 58) to group the networks in your organization and simplify how you see the model in Skybox View. Note: This step is optional but recommended especially for large networks. Workflow for importing a Cisco IOS router The following is the workflow for importing one Cisco router using an Import Directory task. The same basic workflow is used to import other network devices, although the data files (and the commands that produce them) and data format differ from device to device. Skybox Risk Control version

52 Skybox Risk Control User s Guide 1 Connect to the device. 2 Create the following files: run.txt: Output of either of the following Cisco commands: show running-config or show config route.txt: Routing table information; output of the Cisco command: show ip route vrf * 3 Download the files to your computer. 4 (If they are not already running) Start the Skybox View Server and Manager. 5 Create a task to import the router configuration: a) Click. b) In the Operational Console tree, select the Tasks node. c) Click. d) Type a Name for the task, such as Import Cisco router. e) In the Task Type drop-down list, select Import Directory. f) In the Set 1 section, in the Directory field, type the full path to the directory where you saved the files in step 3. 6 Click Launch. 7 Verify that the task finished successfully: a) Select the task in the Table pane of the All Tasks node. b) Check that the value of the Exit Code is Success. If the task did not succeed, look in the Messages tab of the Details pane for information about what went wrong. This tab displays a log of the task; you can view the errors there to understand the problem. For example, a necessary file was deleted for some reason or moved to a different location. 8 Close the Operational Console. 9 Validate that the import is correct and complete: a) In the Model tree select All Network Devices > Routers. b) Do one of the following to confirm that the import succeeded: For a new device (one imported for the first time), check whether the imported device is now part of the list in the Table pane. For an existing device, check that the modification time of the device is the time of the current import, rather than that of a previous import. Skybox Risk Control version

53 Chapter 10 Building the model c) Check that the network interfaces were imported correctly. Right-click the device and select Firewall Map. You can see all imported network interfaces and the networks to which they are attached. Clouds Close the firewall map when you finished. d) Right-click the device and select Routing Rules. Check that the routing rules were imported (that is, Skybox View contains a list of routing rules for this device.) e) Use a sample routing rule to confirm that it was imported correctly: take one routing rule that exists on the device and try to find its logical match in the routing rules in Skybox View. Note: A correctly imported set of routing rules (or access rules) logically matches the set of rules on the device. However, some individual rules may not be modeled in exactly the same way as they are in the device. f) If the device has access rules, right-click the device and select Access Rules. Confirm that the access rules were imported. g) Take one access rule that exists on the device and try to find its logical match in the access rules in Skybox View. h) Click. The device is highlighted in the Network Map. Make sure that the imported device is visible and that it is correctly connected. Clouds are special network objects that represent networks that are connected to the model but are not modeled completely, such as the internet, partners, or parts of your organization s network that are not modeled. A network over which your organization has no control or for which it is unable to obtain device configurations and scan data, should be modeled as a cloud. Clouds are used to model missing areas so that you can analyze access between the surrounding areas or to and from the missing areas. There are two types of clouds: Perimeter Clouds: Perimeter Clouds (commonly referred to as clouds) represent networks or areas in your network at the perimeter of the network, such as partner networks and the internet. Skybox Risk Control version

54 Skybox Risk Control User s Guide Connecting Clouds: Connecting Clouds represent missing areas in the middle of your organization s network. These may be parts of your network for which you are unable to obtain data or Multiprotocol Label Switching (MPLS) networks between various parts of your organization s network. Perimeter Clouds are usually user-defined, but may be created automatically using tasks of type Model Completion and Validation (Convert Perimeter Networks to Clouds option). For information about these tasks, see Model completion and validation tasks, in the Skybox View Reference Guide. Connecting Clouds are always user-defined. For cloud parameters, see Clouds, in the Skybox View Reference Guide. Creating and editing Perimeter Clouds You can create Perimeter Clouds manually or automatically. Creating Perimeter Clouds automatically To create Perimeter Clouds automatically, use a Model Completion and Validation task and select the Convert Perimeter Clouds to Networks option before running the task. For additional information, see Model completion and validation tasks, in the Skybox View Reference Guide. You can also create Perimeter Clouds manually. Creating Perimeter Clouds manually The easiest way to create a Perimeter Cloud is to define an existing network as a Perimeter Cloud. However, this is not sufficient when the Perimeter Cloud represents an area outside the boundaries of your organization s network (such as the internet or a partner organization). When you create a Perimeter Cloud that is not based on an existing network, include and exclude IP addresses as appropriate for the network that you are configuring. The following are some examples of IP addresses to include or exclude: If you are configuring an internet cloud, exclude the IANA reserved addresses (click Private in the Network Properties dialog box). If you are configuring a public network, you must exclude public IP addresses used by your organization. Failure to do so might produce erroneous results in access analysis queries due to spoofed access. If you know the specific IP addresses for the Perimeter Cloud, configure them in the Cloud Addresses tab. To define a network as a Perimeter Cloud 1 In the Model tree, expand the Locations & Networks node and locate the network that you wish to define as a cloud. 2 Right-click the network and select Define Network as Cloud from the shortcut menu. Note: If the cloud is connected to multiple networks, set the IP Address and Mask fields to / To create a Perimeter Cloud 1 In the Model tree, expand the Locations & Networks node and locate the parent node for the cloud. If the cloud belongs at the top level, the parent node is the Locations & Networks node. 2 Right-click the parent node and select New > Perimeter Cloud. 3 In the New Perimeter Cloud dialog box: a) Type a Name for the cloud. b) Set the IP Address and Mask fields to / Skybox Risk Control version

55 Chapter 10 Building the model This enables the cloud to be connected to network interfaces of multiple devices. (A cloud s IP address has no influence on access analysis; the Cloud Addresses tab is used to define the scope of the cloud.) c) Define the scope of the cloud using the two panes in the Cloud Addresses tab: Include: A list of IP address ranges to include in the scope of the cloud. Exclude: A list of IP addresses to be excluded from the scope of the cloud defined in the Include pane. d) In the Routable from Cloud tab, define the IP address ranges that are allowed as destination addresses when access is checked from this cloud. These destination address ranges are used for all queries starting at the cloud in attack simulation and the Access Analyzer. Include: A list of IP address ranges to be used as destination addresses from this cloud. Exclude: A list of IP address ranges to be excluded from the destination address ranges. e) Click OK. For additional information about Perimeter Clouds, see Clouds, in the Skybox View Reference Guide. Attaching Perimeter Clouds to the network After you create Perimeter Clouds manually, you must attach each one to the routers or firewalls in your organization that border that cloud. To attach a Perimeter Cloud to a router or firewall 1 Do one of the following: In the Network Map, right-click the device and select Network Interfaces. In the tree, navigate to a node containing the device, such as All Network Devices > Firewalls; in the Table pane, right-click the device and select Network Interfaces. Figure 18: Network Interfaces dialog box Skybox Risk Control version

56 Skybox Risk Control User s Guide 2 Select the network interface to be attached to the Perimeter Cloud network and click Modify. Figure 19: Network Interface Properties dialog box 3 In the Network field, select the desired Perimeter Cloud. 4 Click OK. Connecting Clouds You use Connecting Clouds to represent missing networks (or groups of networks) between two entities in the model, such as sensitive areas in your organization which cannot be fully modeled. Once these networks are modeled, the Access Analyzer can analyze access through them. Where are Connecting Clouds needed? Connecting Clouds are often needed when you are creating the model and some parts of your organization s network are not included. Sometimes, you know that certain areas were not imported. Other times, you can use the Network Map to show all gateways that have missing next hops (that is, next routing hops that are mentioned in the routing table but are not connected to the gateway in the model) and then decide which of them must be connected. Viewing gateways with missing next hops To view gateways with missing next hops 1 Make sure that a task of type Model Completion and Validation has run since the last time any imports were done. Among other things, this task checks all gateways for missing next hops. Skybox Risk Control version

57 Chapter 10 Building the model 2 Open the Network Map. If necessary, open the map that displays the part of the model on which you want to focus. 3 In the Highlight pane, select Has Missing Next Hops. All gateways with missing next hops are highlighted. When you move your mouse over one of these gateways, you can see a list of its missing next hops. Creating Connecting Clouds The easiest way to create a Connecting Cloud is to select two (or more) gateways and networks in the map that should be connected and then create a Connecting Cloud from them. You can also select two gateways, networks, or network interfaces in the Table pane and create the Connecting Cloud from there. To create a Connecting Cloud 1 Select the gateways or networks in the map that are missing connections between them. 2 Right-click and select Connect via Cloud from the shortcut menu. 3 In the Connect Networks via Cloud wizard, type a Name for the new cloud and click Next. 4 In the top pane, review the list of gateways and networks. If every item in the list includes a network, click Finish to create the cloud from the specified networks. Otherwise (if there are gateways with unspecified networks): for each such gateway, select the network interface of the network to be used to connect to the cloud. The following fields might be helpful in deciding which network interface to use: The Missing Neighbors field indicates which of the network interfaces has missing neighbors. The Potential Match field indicates whether the network interface is considered a good match for the new connection. Once you select a network interface for the gateway, the network to which that network interface is connected appears next to the gateway in the top pane. 5 Repeat step 4 for each gateway that has unspecified networks. 6 Click Finish to create the cloud from the specified networks. For further information about the parameters of Connecting Clouds, see Connecting Clouds, in the Skybox View Reference Guide. Adding additional connections You can add gateways and networks to an existing cloud. To add entities to a Connecting Cloud 1 Select the desired gateways and networks; right-click and select Connect via Cloud. 2 In the Connect Networks via Cloud wizard: a) Select Existing Connecting Cloud, select the desired cloud, and click Next. b) In the top pane, review the list of gateways and networks. c) For each gateway with unspecified networks, select the network interface of the network to be used to connect to the cloud. The following fields may be helpful in deciding which network interface to use: The Missing Neighbors field indicates which of the network interfaces has missing neighbors. Skybox Risk Control version

58 Skybox Risk Control User s Guide Locations The Potential Match field indicates whether the network interface is considered a good match for the new connection. Once you select a network interface for the gateway, the network to which that network interface is connected appears next to the gateway in the top pane. d) Once every item in the list includes a network, click Finish to add the selected entities to the selected cloud. A large organization may include hundreds of networks. Locations are container entities that create a hierarchic structure for networks in your organization, to make it easier to navigate and view the network structure. A location may include networks and sublocations. For example, a Europe location might contain specific networks and London and Paris locations. These locations, in turn, might each include sublocations or networks. Figure 20: Sample locations hierarchy Define locations manually in the Model workspace and then add networks or additional locations to them. Note: You can also create locations using Skybox View s Integration XML (ixml). For information about ixml, see the Integration part of the Skybox View Developer s Toolkit. When working with a large networks, define a location for each physical location that you discover and add to it the networks discovered in that network segment. A location can be a very broad grouping, such as Europe, or a much more local grouping, such as IT Room or 2nd Floor. For a gateway device to be contained in a location, all of its networks must be in that location. If even one network belongs to another location (or is not associated with any location), the gateway device appears on the map even when all locations are collapsed. It is recommended that you include gateway devices (such as routers and firewalls) that are internal to a location as part of the location; do not include gateway devices that connect two or more locations in a location. To add a location 1 In the tree, expand the Locations & Networks node and locate the desired parent node for the new location. If the new location belongs at the top level, select the Locations & Networks node as the parent node. Skybox Risk Control version

59 Chapter 10 Building the model 2 Right-click the parent node and select New > Location. 3 Type a Location Name for the new location. Figure 21: New Location dialog box Location names must be unique throughout the model. The characters / and \ cannot be used as part of a location name. 4 (Optional) Click the Browse button next to the Members field to specify the location s members. Note: If you define the location before you have discovered the topology, you cannot select members for the location. 5 (For a specific Skybox View user to receive notifications about entities in this location) Click the Browse button next to the Owner field to specify the location s owner from all authorized Skybox View users in your organization. Skybox Risk Control version

60 Skybox Risk Control User s Guide To add an existing network or location to a location 1 In the tree, right-click the network or location to add to an existing location and select Attach to Location. 2 Do one of the following: Figure 22: Attach Locations to Location dialog box Select the parent location for the selected entity and click OK. To make this entity part of a new location: a) Select the position in the tree where you want the new (parent) Business Unit. b) In the New drop-down (which contains a list of parent types), click Location. c) In the New Location dialog box, type a name and other relevant information. The entity that you are attaching automatically becomes a child of the new parent location; you can add other locations and networks using the Members field. Note: Repeat steps b and c to create a hierarchy of locations. The entity you attach becomes a child of the last selected location in the tree. For example, you have a network named Operations Center and it belongs in Miami, but there are no appropriate locations. The first time you click New, create a location named US. Inside the new US location, create a location named Florida and inside the new Florida location, a location named Miami. The Operations Center network automatically becomes a member of the Miami location. d) Click OK. The new location is created in the selected position in the tree and the selected entity becomes a child node, as do any members selected in step d. Skybox Risk Control version

61 Chapter 11 Network visualization (maps) Once the model is built, Skybox View automatically generated a map of all the interconnections: the Network Map. Figure 23: Sample Network Map To open the Network Map from Skybox View Manager, click on the toolbar. Each time you open it, the Network Map is redrawn according to the most recent information in your model. You can create and save maps of specific sections of your network as needed. The Network Map can help you to understand the network topology, focus on specific parts of the network, identify disconnections, and more. In this chapter Creating and saving dedicated maps Navigating the Network Map Map Groups Creating and saving dedicated maps The default Network Map includes the entire model. However, it is generally easier to work if you create dedicated maps for specific scopes. It is recommended that you create a separate map for each network scope that you want to view in detail, such as a specific location or environment. Skybox Risk Control version

62 Skybox Risk Control User s Guide Creating an initial map You cannot save changes to the default map, but you can create a map based on the default map and then save the changes. To create a map based on the default map 1 With the default map open, in the File pane of the control panel, click. 2 In the Save Network Map as dialog box, type a name for the map and click OK. Creating a dedicated map To create a map 1 In the File pane of the control panel, click. Figure 24: New Network Map dialog box 2 Define the scope of the map using the Network Scope field and, if necessary, the Network Exclude Scope field. For additional information about the parameters of Network Maps, see Network Map parameters, in the Skybox View Reference Guide. 3 Click OK. Saving maps To save a map Do one of the following: To save the current map including any changes that you have made: In the File pane of the control panel, click. Skybox Risk Control version

63 Chapter 11 Network visualization (maps) To save the current map with a different name: In the File pane of the control panel, click Viewing changes to the map. Changes to the model (for example, import of new devices) that take place while the Network Map window is open are not automatically reflected in the map. If you know that changes were made, click at the top of the control panel. You are prompted to save all unsaved maps, the map definitions from the Server are refreshed, and the selected map is reloaded to the Map pane. Navigating the Network Map Navigation of the Network Map is done using the control panel. Map layout Skybox View lays out the nodes of the selected map according to a specific formula. If necessary, you can select and move nodes of the map to make the map easier for you to work with. You can also do any of the following: Click. Skybox View redraws the map using the same calculation formula. This is useful if you have changed the display somewhat (for example, if you have created map groups or hidden some nodes). The results may be easier for you to use. If you have not changed the display, or if the relayout does not make the map easier for you to use, adjust the layout properties using the Layout pane ( ) to change the parameters of the calculation formula. For additional information, see Layout parameters, in the Skybox View Reference Guide. Skybox Risk Control version

64 Skybox Risk Control User s Guide Click. Skybox View redraws the map to fit the current size of the window. Select anywhere inside the white space of the map and scroll to resize the map, or move the mouse to reposition the map in the window. Highlighting parts of the map Skybox View can highlight specific nodes or sets of nodes in the map to help you understand your organization s network. Highlighting is temporary: when you change maps or save a map, all highlighting is turned off. Highlighting neighbors: By default, when you select a node in the map, the node is highlighted, and its immediate neighbors are also highlighted, in a lighter color than the selected node. This makes it easier to see the context of the selected node. You can change the number of neighbors highlighted each time by changing the value of the parameter. Note: The value of this parameter is saved with the map. Highlighting different types of nodes: Use the Highlight pane to define types of nodes that are to be highlighted in the map (automatically, not by selection). For example, you can highlight all firewalls, all perimeter clouds, a specific location, or nodes that have missing next hops. Each type of node is highlighted in a different color, and you can select more than one type to highlight at the same time. Filtering the map Skybox View enables you to filter the map to display only specific nodes. To display the filter pane, click in the control panel. Figure 25: Network Map Filter pane Note: You can also use Ctrl-F to display the filter pane, and Esc (in the Show field or in the white space of the Map pane) to close it. Show: Select nodes in the map by typing in the (full or partial) name or IP address of the desired nodes. Only these nodes (and their neighbors) are displayed. You can use standard wildcards (? and *) in the filter. You can also use the following regular expression syntaxes: ^X: Specifies an expression (X) which appear at the beginning of the name or IP address X$: Specifies an expression (X) which appear at the end of the name or IP address [xyz]: Specifies a single character, which is either x, y, or z [^abc]: Specifies a single character, which can be anything except a, b, or c Show Only Highlighted: Filters the map to show only highlighted nodes. Regular Mouse Mode: Specifies that when you select nodes in the map, the selected nodes and their neighbors are highlighted. Focus: Specifies that when you select nodes in the map, only those nodes and their neighbors (within a radius of Neighbors Distance) are shown. All other nodes in the map are hidden. Extend: Specifies that when you select nodes in the map, the map expands (if parts of it were hidden) by adding all neighbors of the selected node up to a radius of Neighbors Distance. Skybox Risk Control version

65 Chapter 11 Network visualization (maps) Display All Nodes: Restores all hidden nodes to the map but keeps the current magnification (so that not all the nodes may be visible in the display). Note: This button clears all highlighting. Exporting maps Skybox View enables you to export maps as graphic files or Visio files. Export image: Saves the visible portion of the map as a graphic to the folder you select in the Export dialog box. Note: You can adjust the resolution of the saved image in the Export dialog box for easier viewing outside of Skybox View. Export to Visio: Exports the visible portion of the map as a Microsoft Visio drawing file (*.VDX) so that non-skybox View users can view or print the map. Note: VDX is a standard XML drawing format supported by Visio. For additional information about the control panel and the filter pane, see Network Map control panel, in the Skybox View Reference Guide. Map Groups A Map Group ( ) represents a region or area in the network. Map Groups may include gateways, networks, and other Map Groups. Normally, map group members are topologically related, so that a collapsed group makes sense. Defining Map Groups reduces the complexity of the model in the Network Map and provides better orientation in large networks. Each Map Group can be highlighted in a different color, enabling you to easily view which entities belong to which groups. You can collapse a Map Group so that only a representative node is shown in the map. Map Groups are stored globally in the model; creating or changing a Map Group in one map affects all other maps that contain that Map Group. Map Group scopes Each Map Group has a set of defining members (which typically consists of the group s gateways) and additional members. The additional members are the neighbor nodes of the defining member nodes that all their neighbors appear in the scope. The defining member nodes are specified by the user. The additional member nodes are automatically completed by Skybox View. This makes the Map Group definition more compact and eliminates the need to explicitly attach newly discovered networks to any Map Group; newly discovered networks are automatically added to the Map Groups of their gateway neighbors. Creating Map Groups Before defining new Map Groups it is recommended that you: Set the Highlight mode of Map Groups to All (in the Map Group pane, in the Highlight field, select All). This highlights each existing Map Group in a separate color, and highlights new groups in different colors as they are created. Set the Highlight Neighbor distance (at the top of the Control Panel) to 0. This prevents highlighting neighbor nodes when selecting nodes for a Map Group. Skybox Risk Control version

66 Skybox Risk Control User s Guide To create a new Map Group 1 Select the set of nodes that define the scope of the Map Group. Nodes (gateways and networks, but not Perimeter Clouds) whose neighbors all appear in the scope of the Map Group are automatically added to the group as members. Therefore it is usually sufficient to select a set of gateway nodes as the defining members. It is only necessary to select network nodes explicitly if they should be part of the group but some neighbor gateways are not part of the group. 2 Right-click in the selection and select New Map Group. 3 In the Map Group dialog box: a) Type a Name for the group. b) If necessary, change the highlight color of the group. c) If you want the group displayed in collapsed form after it is created, select Collapse. d) Click OK to create the Map Group. Note: Map Groups have labels. You can use the View pane of the Control Panel to define whether their labels are displayed. (By default, all labels are displayed.) Map Group hierarchies To create a hierarchy of Map Groups, you can work top-down (for example, by creating a Paris Map Group when a Europe Map Group already exists) or bottom-up (for example, by creating a Europe Map Group when Paris and London Map Groups already exist). To create a Map Group inside an existing Map Group 1 Select the nodes of the existing Map Group that are to be included in the new Map Group. 2 Right-click in the selection and select New Map Group. To create a new Map Group that contains existing Map Groups 1 Select the labels of the existing Map Groups (and other gateway or network nodes as necessary). 2 Right-click in the selection and select New Map Group. To view the hierarchy of Map Groups 1 Right-click a node in the map and select Attach to Map Group. 2 In the Attach to Map Group dialog box, view the Map Group hierarchy and then click Cancel to close the dialog box (without attaching anything). Working with Map Groups The following commands in the Map Groups pane of the Control panel are useful when working with Map Groups: Highlight All: Highlights each Map Group in a different color Collapse All/Expand All: Collapse or expand all Map Groups. Collapse replaces the members of a map group by a representative node. The following commands from the shortcut menu are useful when editing Map Groups: Collapse Map Group: Right-click a member of the Map Group or the group s label, and select Collapse Map Group. Expand Map Group: To display all the member of a collapsed Map Group, right-click the node representing the Map Group and select Expand Map Group. Skybox Risk Control version

67 To attach nodes to a Map Group Chapter 11 Network visualization (maps) 1 Select a set of nodes or labels of Map Groups to be attached to another Map Group. 2 Right-click in the selection and select Attach to Map Group. 3 Specify the target Map Group in the dialog box. The selected nodes or Map Groups are detached from previous Map Groups that they were attached to (if any) and are attached to the selected target Map Group. To detach nodes from a Map Group 1 Select a set of nodes or labels of Map Groups to be detached from the Map Groups to which they are currently attached. 2 Right-click in the selection and select Detach from Map Group. To delete a Map Group 1 Select a Map Group (by selecting either the Map Group s collapsed node or its label). 2 Right-click the selection and select Delete Map Group. Note: This command deletes the map group definition. It deletes neither the member nodes of the map group nor any subgroups of the selected group. Skybox Risk Control version

68 Chapter 12 Validating the model The Skybox View model is a topology map of the network structure across geographic locations and datacenters, allowing drill down views of firewall policies, router configurations, and IPS rules. However, the model is only as accurate as the data it contains. Missing or incorrect information affects the accuracy of the results. As the model is built, you must validate the correctness and completeness of its information. This section explains the validation process. In this chapter Overview of validating the model Verifying completeness Model completion and validation Using model validation analyses Verifying topology Verifying access Validating the setup for attack simulation Overview of validating the model Whenever new data is added, verify that the model meets the following two criteria: Completeness: There are no missing elements in the model (such as routers, firewalls, networks, Perimeter Clouds or assets). Correctness: The model reflects the actual network (the topology was correctly interpreted; Perimeter Clouds are connected to the correct interfaces, and so on). Inconsistencies can occur because data is collected using different methods. For example, routing rules on a gateway might point to a non-existent router, indicating that data collection is incomplete; the missing device must be added to the model. Note: Severe inconsistencies compromise attack simulation results. Validate the model: After every milestone (for example, after adding a segment of your network to the model) to ensure that the model represents the actual access in your organization s network. After collecting data and building the model, before you move on to the analysis stage. Validation methods to use while building the model (and on a continuous basis) include: Discovery Center: Check that the numbers there match what you expect. Also, use it as a way to tell whether the model needs to be updated. Task error messages: Error messages from collection tasks and import tasks may mean that something went wrong. Item counts: Check that the number of servers, workstations, routers, and firewalls added to the model is what you expected, and that the element names and types look right. Skybox Risk Control version

69 Chapter 12 Validating the model Network Map: After you have built the basic topology of the network, use the Network Map to make sure that the whole network is connected. Unconnected nodes or network segments are a sign of missing information. Access Analyzer: Check the access to the corporate network from various locations (such as the internet or a partner cloud network). If there is insufficient access, gateways may be missing in the model. If there is too much access, sets of access rules may be missing. Model validation analyses: The built-in model validation analyses show lists of entities that might need to be fixed. The most important ones to check at this stage are those that show gateway issues and network interfaces with problems. These methods are explained in more detail in the following sections. Verifying completeness The first step in validating the model is to check that everything that you expected was imported successfully. Use the Model tree and the list of devices that you imported to Skybox View to check that all of the devices you imported are actually in the model. To check that the model is complete 1 Check that all routers were successfully imported: in the Model tree, select All Network Devices > Routers. Look at the list of routers in the Table pane to make sure it is what you expected. If necessary, select a router in the list to view additional information in the Details pane. 2 Use the same method to check successful import of: Firewalls: Select All Network Devices > Firewalls. Workstations: Select All Assets > Workstations. Servers: Select All Assets > Servers. Model completion and validation The next step, after checking that all the entities you expected were imported, is to run a Model Completion and Validation task. These tasks check the model for completeness and correctness. The tasks check for missing elements and can also modify the model in various ways, such as by: Creating perimeter clouds Updating the assets in a Business Asset Group when the Business Asset Group is defined by networks and not by specific assets Updating cloud IP addresses The tasks also provide information to Model Validation analyses and to the Network Map, such as: Whether any gateways are missing routing rules Whether any routers have missing next hops (and the expected IP addresses of those next hops) Whether any firewalls have no access rules Note: Changes to the model made after this task is run are not reflected in the Model Validation analyses or in the missing next hops of the Network Map. For information about the parameters of Model Completion and Validation tasks, see Model completion and validation tasks, in the Skybox View Reference Guide. Skybox Risk Control version

70 Skybox Risk Control User s Guide Using model validation analyses Model validation analyses list entities that are or might be problematic. Note: The entities in these analyses must be examined. For example, an asset that has no vulnerability occurrences usually means that the asset was not scanned for vulnerability occurrences, but it might be an asset that has no vulnerability occurrences. Model validation analyses are accessible from the Model tree, under the Model Analyses > Model Validation node. The following analyses provide the quickest indication of possible problems in the model: Gateways Validation > Disconnected Gateways Gateways Validation > Firewalls with No Access Rules Gateways Validation > Gateways with No Routing Rules Network Interfaces Validation > Interfaces with Connectivity Issues Note: Network interfaces that have missing next hops are especially problematic. Assets Validation > Assets with No Vulnerability Occurrences Verifying topology Verifying the topology involves: Verifying the internal topology of the model to confirm that it is complete (see page 70). Verifying the external connections of the model (see page 71). Use the Network Map to highlight missing hops from existing gateways in the model, if the model is missing at least one next hop from the routing table of a device. To view devices with missing next hops in the map, select Has Missing Hops in the Highlight pane of the map s control panel. Verifying the topology of the model Using the Network Map, you can easily see whether any gateways or networks are disconnected or if the connections are not what you expected. Skybox Risk Control version

71 Chapter 12 Validating the model The following map shows an incomplete model; at least one additional gateway is missing that would connect the two parts. Figure 26: Incomplete Network Map If the Network Map of your model has unconnected parts or missing hops, consult your list of devices to figure out what is missing. For additional information about the Network Map, see Network visualizations (maps) (on page 61). Verifying external connections Include every connection from an external network in the model. Connections from partners, suppliers, extranets, VPN communities, and ISPs must all be modeled using Perimeter Clouds. Failing to include an external connection might result in inaccurate risk and vulnerability occurrence information in Skybox View reports and analyses. To verify external connections 1 Compare the network diagram (of the currently modeled scope) to the map generated by the model. For each network in the scope, verify that it exists in the model and that it has the same number of external connection points. 2 Check the Include and Exclude lists of Perimeter Clouds that model external connections. These clouds should exclude all network IP addresses that are used internally. Skybox Risk Control version

72 Skybox Risk Control User s Guide Fixing the topology If the Network Map of your model has unconnected parts or missing next hops, consult your list of devices to figure out what is missing, and do any of the following: If specific devices were not imported, import them, run the Model Validation task, and check the Network Map again to see whether the model is now complete. If you imported all devices on your list but holes remain or if you do not have access to the configuration for devices that are responsible for connectivity between different parts of the model, connect the disconnected parts of the model using a Connecting Cloud (right-click the relevant entities and select Connect via Cloud). For additional information, see Creating Connecting Clouds (on page 57). If there are missing next hops at the perimeter of the model, create Perimeter Clouds. For additional information, see Creating Perimeter Clouds (on page 54). Verifying access There are two ways to verify access: Test connectivity in the model (see page 72) between various standard locations using the Access Analyzer. The Access Analyzer models the connectivity between any two points in the network model and lists which protocols are accessible or inaccessible taking into consideration the network routing rules and access rules. (Optional) Compare access in the physical network with access in the model by comparing traceroutes in the network with the results of the Access Analyzer. Testing connectivity The following are some standard ways to test connectivity. You should use several of them to check connectivity in the model. From the internet to internal networks 1. Click to open the Access Analyzer. 2. Select Internet (or the largest cloud defined in the model) as the Source. 3. Select an internal network populated by Windows assets as the Destination. 4. Click to display all accessible assets and their (accessible) ports. In most networks, no access is allowed from the internet to internal client networks. From the internet to the DMZ servers Use the Access Analyzer to find all connections allowed between Internet and DMZ network with internet-accessible servers. The list of accessible servers and ports should match the policy of the firewall protecting that DMZ. Can internet-based users reach all important public services on the DMZ? From the DMZ to internal servers Use the Access Analyzer to find all connections allowed between the DMZ network and all internal networks. Access rights should match the outbound policy on the DMZ firewall and the inbound policy on the internal firewall. Multi-tier applications must have specific access rules. Can the web and application servers located on the DMZ contact the appropriate database server ports on the internal network? Skybox Risk Control version

73 From a partner network to internal servers Chapter 12 Validating the model Use the Access Analyzer to find all connections allowed between the partner s client machines and the internal organization. The accessible services must match the rulebase on the firewall facing the partner link. Can the partner access all required applications? Between two internal networks Use the Access Analyzer to find all connections allowed between two internal networks. Depending on the internal policy, all connections might be allowed. If Access Analyzer results show unwanted or unexpected access, check for a firewall configured as a router without access rules. Check for speculative routing on gateways that use dynamic routing protocols. Also check the internet and other perimeter clouds. Private, internal, and non-routable IP addresses must be excluded from these external objects. If Access Analyzer results show that expected or desired access is not available, the model is probably missing a network device, network segment, or other connecting link. Validating the setup for attack simulation Skybox View attack simulation produces accurate results only if attack locations are defined throughout the network. Define a Threat Origin for every external link from which an attack might originate. Attack simulation is also dependent on the definition of important internal resources. Every server that provides a revenue or productivity function should be a member of a Business Asset Group and at least one Business Impact should be associated with every Business Asset Group. Manual verification is the only method available for checking the configuration of Business Asset Groups and Business Impacts. To validate the business information 1 Compare the list of Business Asset Groups in the model with the list provided during the deployment-planning phase. 2 Compare the model with access rules: a) Look through the firewall rulebase that protects the server networks. b) For each specific inbound service rule, verify the importance of the service. c) In the model, check that the service s asset belongs to a Business Asset Group. 3 Most organizations maintain separate networks for servers. Examine the server networks: a) Check that all members of the server network are providing at least one service. b) Check that every server is inactive, unimportant, or part of a Business Asset Group. Skybox Risk Control version

74 Chapter 13 Adding Threat Origins A Threat Origin is a potential starting point for an attack. It is specified by defining the network entities (assets, networks, or locations) where an attacker or worm could be located. Threat Origins are indicated in Skybox View by. The following are typical locations for Threat Origins: Perimeter Clouds (such as a partner s network or the internet) For information about how to define Perimeter Clouds, see Creating and editing Perimeter Clouds (on page 54). Locations where you expect mobile devices to be connected Points inside your organization that you suspect could be the source of an internal attack Locations in which the security level is limited, such as DMZ networks or workstation networks (which are prone to infection via ) To enable effective risk analysis of your corporate network, you must specify the Threat Origins that seem most probable for your organization. Note: As stated in First phase (on page 205), it is recommended that you start with a first phase consisting of one or two threats. Attack simulation tests all scenarios for attacking the network starting from the Threat Origins defined in the model and it uses this information to analyze risk. In this chapter Threat Origin types Threat Origin Categories Defining Threat Origins Disabling and enabling Threat Origins Threat Origin types There are two basic types of Threat Origins: Human Worm Human Threat Origins Properties of human Threat Origins include the estimated skill level of the attackers and the attacker s privilege on the attacking computer. For example, for human Threat Origins from the internet, you assume the existence of highly skilled attackers, but for some human Threat Origins inside your organization, you assume that the attackers are less skilled. The skill level is taken into account when analyzing the likelihood of successful attacks and the risks imposed by these attacks. Skybox Risk Control version

75 Chapter 13 Adding Threat Origins You can specify which Business Asset Groups a human Threat Origin can attack. When defining a Business Asset Group, you can define the human Threat Origins that you expect might attack it. By default, human Threat Origins attack all Business Asset Groups. Worm Threat Origins A worm Threat Origin can include worms from the Skybox View Dictionary. Worms are assumed to attack any asset in their path (unless prevented by a firewall), so it is not necessary to define relevant Business Asset Groups. Threat Origin Categories Threat Origins are classified into Threat Origin Categories, so that they can be easily grouped when risk is displayed or reported. For example, you can show risk for, or create a report about, all Threat Origins that originate outside your organization (usually named External Threats). To view risk from specific threats in an analysis or a report, add those threats to a Threat Origin Category and select that category to filter the analysis or report. Skybox View includes five Threat Origin Categories with the following default names: External Threats Internal Threats Worm Threats B2B Threats Other Threats Note: The Other Threats category is disabled by default. You can enable it if you need an additional category. A Threat Origin can belong to more than one category. For example, a human attacker from the internet could be classified as external and B2B. You can create analyses that return only Threat Origins in specific categories, such as External and B2B (hackers), or Internal and B2B (employees who may be leaking information to outside sources). Managing Threat Origin Categories Note: Only Admins can manage Threat Origin Categories. Renaming Threat Origin Categories Although you cannot define additional categories, you can tune the existing categories to suit your organization by renaming them. For example, you can change two of the Threat Origin Categories to Internet and Competitors, and define each Threat Origin accordingly. To rename a Threat Origin Category 1 In the Threat Origin Categories branch of the Model tree, right-click the desired category and select Rename. 2 Type a new name for the category. The new name is used wherever this Threat Origin Category is mentioned, such as in the column names of specific analyses, the Risk Profile tab of Business Units, Business Asset Groups, and vulnerability occurrences, and the filtering fields of analyses and reports about Threat Origins. Enabling and disabling Threat Origin Categories You can enable or disable Threat Origin Categories as necessary. Skybox Risk Control version

76 Skybox Risk Control User s Guide To enable or disable a Threat Origin Category In the Threat Origin Categories branch of the Model tree, right-click the desired category and select Enable or Disable. Note: Enabling or disabling a Threat Origin Category does not affect the status of Threat Origins in that category. Threat Origins are always accessible from the All Threat Origins node of the Model tree. However, you can only view the risk from Threat Origins in a category as part of the total risk for that category. Defining Threat Origins When defining a Threat Origin, take into account that Threat Origins do not attack themselves, and Skybox View does not analyze attacks between assets or networks that are part of the same Threat Origin. Therefore, if you define a Threat Origin with several locations, Skybox View does not analyze attacks between the assets or networks in those locations. As a large number of Threat Origins can make it harder to understand the risk, use a small number of Threat Origins. Defining human Threat Origins To define a human Threat Origin 1 In the Model tree, expand the Threat Origin Categories node. 2 Right-click All Threat Origins and select New > Human Threat Origin. 3 Type a name for the Threat Origin. Figure 27: New Threat Origin dialog box 4 Click the Browse button next to the Threat Location field to define the location of the Threat Origin. 5 Select at least one Threat Origin Category. Skybox Risk Control version

77 Chapter 13 Adding Threat Origins 6 Specify the Attacker Skill and the Likelihood to Attack. Note: It is important to define the likelihood in a way that differentiates between more probable and less probable attack sources. 7 Click OK. The Threat Origin is saved. You can see it in the Table pane when you select the appropriate Threat Origin Category node in the Model tree. For additional information about the parameters of Threat Origins, see the Threat Origins section in the Skybox View Reference Guide. Advanced parameters are available in the Advanced tab. In most cases, you can use the default values. Advanced parameters include: Attacker Privilege (can be changed from Root to User). Business Asset Groups: By default, each Threat Origin can potentially attack all Business Asset Groups. If there are Business Asset Groups that this Threat Origin cannot or will not attack, configure the Threat Origin so that Skybox View ignores them during risk analysis: Select each such Business Asset Group in the Analyze for risk field and click to move them to the Ignore field. Cloud source addresses: Risk for Threat Origins is usually assigned an equal value from all types of source IP addresses. In some cases, the risk for attacks from wide address ranges and the risk for attacks from specific addresses should be different; for information about handling this issue, see Using clouds as Threat Origins (on page 149). Skybox Risk Control version

78 Skybox Risk Control User s Guide Defining worm Threat Origins To define a worm Threat Origin 1 In the Model tree, expand the Threat Origin Categories node. 2 Right-click All Threat Origins and select New > Worm Threat Origin. 3 Type a name for the Threat Origin. Figure 28: New Worm Threat Origin dialog box 4 Define the threat s location, select at least one Threat Origin Category, and specify Likelihood to Attack. Note: It is important to define the likelihood in a way that differentiates between more probable and less probable attack sources. 5 Select the type of worm represented by this Threat Origin: Network Messenger/Chat Zero-day 6 Specify whether Skybox View is to select all worms of this type (Automatic Worm Selection) or whether worms are to be selected manually (Manual Worm Selection). Skybox Risk Control version

79 Chapter 13 Adding Threat Origins 7 If you specified Manual Worm Selection in the previous step, use the Available and Selected fields to select specific worms for the Threat Origin. 8 To define whether to include worm risk as part of the total risk to your organization, click Worm Settings. Note: You can access the Worm Settings parameters at other times (select Tools > Options > Server Options > Worm Settings). 9 Click OK. The Threat Origin is saved. You can see it in the Table pane when you select the appropriate Threat Origin Category node in the Model tree. For additional information about the parameters of Threat Origins, see the Threat Origins section in the Skybox View Reference Guide. Adjust the parameters of cloud Threat Origins in the Advanced tab. Risk for cloud Threat Origins is usually assigned a value equal to that from all types of source IP addresses. In some cases, the risk for attacks from wide address ranges and from specific addresses should be different; for information about handling this issue, see Using clouds as Threat Origins (on page 149). Disabling and enabling Threat Origins By default, Threat Origins are enabled. Disabling Threat Origins can be useful in the following circumstances: If (while building the model) not all firewalls are defined in the model, the Threat Origins have access to large parts of the network. This may slow down attack simulation and may also mean that Skybox View shows very high risk on all Business Asset Groups (some of which would not be accessible if the firewalls were defined). Disabling Threat Origins speeds up attack simulation and cuts down on the amount of risk shown. To evaluate the risk from a specific Threat Origin, you can disable the others. To disable or enable a Threat Origin In the Table pane, right-click the Threat Origin and select Disable or Enable. Disabled Threat Origins are shown with a grayed out icon ( ) instead of a regular one. Skybox Risk Control version

80 Chapter 14 Adding Business Asset Groups A Business Asset Group is a group of assets that serve a common business purpose. Use Business Asset Groups to model your organization according to functions provided by your IT infrastructure. When defining a Business Asset Group for security metrics, you name the Business Asset Group and specify its members and possibly an owner. To use Business Asset Groups in Exposure, the following additional information is necessary: Threat Origins which might attack this Business Asset Group Damages from Business Impacts and Regulations that would be caused to your organization if the Business Asset Group suffers a loss of confidentiality, integrity, or availability Dependency rules that define how the assets in the Business Asset Group interact with each other or with other assets and nodes Best practice for defining Business Asset Groups When you start defining Business Asset Groups for Exposure, you might not have all of the information that you need. If you do not have enough information, you could start with a basic set of Business Asset Groups and fine-tune them later. For example, you can create a group of all assets or servers in a specific segment and assign a Business Impact for the entire group. Start with network segments with which you are familiar. As you obtain more information, you can refine the Business Asset Groups. For example, when you start modeling your organization, you know that network /24 contains the servers of an important database. You could create a Business Asset Group to represent that network, specifying a High or Critical Business Impact (security loss). After two months, as a result of gathering information in your organization about the various applications, you realize that network /24 contains two different groups of database servers, each serving a different application. You could then define two separate Business Asset Groups, where each includes a specific set of database servers for one application, and define the Business Impact appropriately for each Business Asset Group. In this chapter Defining a Business Asset Group Business Impacts and Regulations Adding dependency rules Explicit dependency rules Implicit dependencies Defining a Business Asset Group If you already defined Business Asset Groups for security metrics, add the relevant information (member dependency and Threat Origins) to each one. Otherwise, use the instructions below to define new Business Asset Groups. To define a Business Asset Group 1 Do one of the following: In the Model tree, select the Business Units & Asset Groups node. Skybox Risk Control version

81 Chapter 14 Adding Business Asset Groups To make the new Business Asset Group part of an existing Business Unit, select that Business Unit. 2 Right-click the node and select New > Business Asset Group. 3 Type a Name for the Business Asset Group. Figure 29: New Business Asset dialog box 4 Click the Browse button next to the Members field to select the members of the Business Asset Group. Select any of the following: Specific assets Networks If you select a network, every non-network-device asset currently in that network is included in the Business Asset Group. 5 If necessary, change the type of Member Dependency. For information about dependency, see Adding dependency rules (on page 84). Skybox Risk Control version

82 Skybox Risk Control User s Guide 6 All Threat Origins in the model are considered to be potential attackers of this Business Asset Group and are used in the risk analysis of the Business Asset Group. If there are Threat Origins that do not attack this Business Asset Group, set them to be ignored when analyzing risk for the Business Asset Group: Select each such Threat Origin in the Analyze for risk field and click to move the selected Threat Origins to the Ignored field. 7 (Optional) Select an Owner for this Business Asset Group. 8 Click OK. The Business Asset Group is saved. It is added in the Model tree under its parent node. For information about the parameters of Business Asset Groups, see Business Asset Groups, in the Skybox View Reference Guide. Note: Skybox View does not automatically update the association between networks and Business Asset Groups. If any networks are included in the Business Asset Group, you should run a Model Integrity task each time the network is updated. (You can schedule this task to run on a regular basis or as part of a task sequence to run after a task that updates the model, such as a network scan.) For information about tasks of this type, see Model integrity tasks, in the Skybox View Reference Guide. Business Impacts and Regulations An impact is a way of measuring the loss on a Business Asset Group. Impacts involve damage to Business Asset Groups in one of two ways: In the form of a Business Impact (such as mission-critical damage or low-level financial damage) As a compromise to a security regulation with which the organization must comply (such as SOX or GLBA). Business Impacts and Regulations are used by Skybox View to calculate the risk on the Business Asset Group. You define them separately and attach them to Business Asset Groups as appropriate. Note: By default, Skybox View does not take the impact level into consideration for security metrics analysis. Skybox View comes with predefined Business Impact and Regulation templates, and predefined Business Impacts and Regulations for the most common Business Impacts and Regulations. You can use the templates as the basis for creating new Business Impacts and Regulations to suit the needs of your organization. Adding new Business Impacts and Regulations You can add Business Impacts and Regulations directly from a Business Asset Group using the New button or you can add them from Tools > Administrative Tools > Business Impacts (or Regulations). You must specify the Loss Type, Damage Level, and attached Business Asset Groups. Only Admins can create new Business Impacts and Regulations. Best practice for working with Business Impacts It is recommended that you use different Business Impacts for different types of loss or at least to differentiate between confidentiality and integrity versus availability. If you do not find an appropriate Business Impact (or Regulation) for a specific Business Asset Group, add a Business Impact (or ask an Admin to do it for you). Attaching Business Impacts and Regulations to Business Asset Groups The following instructions explain how to attach a Business Impact or Regulation to a Business Asset Group. Skybox Risk Control version

83 To attach Business Impacts or Regulations to a Business Asset Group Chapter 14 Adding Business Asset Groups 1 Expand the Business Units & Asset Groups node of the Model tree and navigate to the Production DB Business Asset Group. 2 Right-click the Business Asset Group and select Properties. 3 In the Production DB Properties dialog box click the Business Impacts tab or, to attach Regulations, click the Regulations tab. Figure 30: Business Impacts tabbed page 4 Select the check box next to each Business Impact that is to be attached to the Business Asset Group. 5 If necessary, change the Damage of a Business Impact for this Business Asset Group: a) Click the Browse button next to the Damage field of the Business Impact. b) In the Damage dialog box do one of the following: Change the Level by selecting a different value from the drop-down list. Click Rate and type the damage in monetary units. Levels are mapped internally to specific monetary values for risk analysis. Rates need not be exact values, but they should indicate the approximate magnitude of the damage. c) Click OK. 6 Click OK. To detach Business Impacts or Regulations from a Business Asset Group 1 Expand the Business Units & Asset Groups node of the Model tree and navigate to the Business Asset Group. 2 Right-click the Business Asset Group and select Properties. 3 In the <Business_Asset_Group_name> Properties dialog box: a) Click the Business Impacts tab or, to detach Regulations, click the Regulations tab. Skybox Risk Control version

84 Skybox Risk Control User s Guide b) Clear the check box next to each Business Impact or Regulation that is to be detached from the Business Asset Group. c) Click OK. Adding dependency rules The security of a Business Asset Group depends on the security of its members. It can also depend on the security of infrastructure servers such as DNS and Authentication servers, and on the security of other assets. Dependency rules allow you to define this dependency and specify how attacks on assets affect the security of the Business Asset Groups. Dependency rules are used by the Skybox View Attack Simulation Engine (exposure analysis) when computing the effects of an attack. Dependency rules relate to the type of security loss. For example, an availability loss of a DNS server might imply an availability loss for a Business Asset Group; a confidentiality loss of a database server usually implies a confidentiality loss for the application that uses that database. Skybox View has two types of dependency rules: Explicit dependency rules between assets and Business Asset Groups (see page 84) Implicit dependencies (see page 85) Viewing dependency rules You can view dependency rules directly from the Model tree (Dependency Rules node). By default, only explicit dependency rules are listed. To view implicit dependency rules Select View > Show Implicit Dependency Rules. Explicit dependency rules Explicit dependency rules express dependency when: The security of a Business Asset Group depends on the security of its members in a way that is not covered by the implicit dependency rules A Business Asset Group depends on an infrastructure server, such as a DNS server or an Authentication server, that is not a member of the Business Asset Group An explicit dependency rule specifies how security loss on a set of specified assets affects the security loss of another set of assets or Business Asset Groups. Dependency rules relate to the type of the security loss (confidentiality, integrity, and availability) and to the type of the dependency: At Least One: A security loss suffered by any of the specified assets affects the destinations. All: Only a security loss suffered by all specified assets affects the destinations. Skybox Risk Control version

85 To define a dependency rule Chapter 14 Adding Business Asset Groups 1 In the Model tree, right-click Dependency Rules and select New Dependency Rule. Figure 31: New Dependency Rule dialog box 2 Type a Name for the dependency rule and, optionally, a description in the User Comments field. 3 In the Cause pane, use the Loss Type, On, and Network Entities fields to describe the cause of the possible damage (for example, an Integrity or Availability loss on All of the web servers in your system). 4 In the Effect pane, use the same fields to describe the effect of the possible damage (for example, an Availability loss on the Back End Payment System). For suggestions on how to use explicit dependency rules, see Explicit dependency rules (on page 150). For information about dependency rule parameters, see Dependency rules, in the Skybox View Reference Guide. Implicit dependencies An implicit dependency defines how the security of a Business Asset Group depends on the security of its member assets. By default, implicit dependency specifies that: A security loss of any type (confidentiality, integrity, or availability) on a member implies the same type of security loss on the Business Asset Group An integrity loss on a member implies an availability and confidentiality security loss on the Business Asset Group This dependency is automatically created when you assign assets to a Business Asset Group. For information about changing the implicit dependency, see Advanced dependency rules (on page 149). Skybox Risk Control version

86 Chapter 15 Simulating attacks Attack simulation simulates all attack scenarios for attacking your organization s network from a set of specified Threat Origins and analyzes the results. The derived data is stored in the Skybox View database. An attack scenario represents a set of actions that an attacker can perform from a specified starting point towards a specified destination, given the specific context of the organization s network: firewall and router configurations, network topology, and existing vulnerability occurrences. Attack simulation is used to examine the ability of potential attackers to attack your organization s network and assets. Because the attack simulation is invoked on a model of your organization s network, it can initiate attacks from every Threat Origin, trying all possible attack paths without causing any load or damage to the network. Attack simulation is launched using the Analyze Exposure task. You can run this task manually, after you have built or made changes to the model (including changing the status of a vulnerability occurrence to Fixed) or you can schedule it. Changes to the risk of an entity or exposure of vulnerability occurrences are only reflected in the analyses after attack simulation is run. Note: Attack simulation involves heavy computations. The task may run for minutes or even hours, depending on the size and complexity of the network. For large, complex networks, it is recommended that you schedule this task at off hours. For information about scheduling tasks, see Scheduling tasks and task sequences (on page 115). To run attack simulation manually Select Tasks > Analyze Exposure. In this chapter Understanding Skybox View risk Understanding Skybox View risk Attack simulation provides information about possible attacks against the corporate network, taking into account the network access constraints and the specific behavior of each vulnerability occurrence. Risk analysis assesses the likelihood of these attacks and the potential damage that they can cause. As part of attack simulation, Skybox View calculates risk for: Business Asset Groups and Business Units Business Impacts and Regulations Vulnerability occurrences Attacks Threat Origins For information about the calculation of risk, see About risk (on page 152). Skybox Risk Control version

87 Chapter 16 Identifying the critical issues After attacks are simulated, the Exposure Summary page highlights the critical exposure issues, including the vulnerability occurrences that are most likely to be exploited and the Threat Origins that have the highest risk. You can drill down from this page to find additional information about each issue. In this chapter Workflow Reviewing the directly exposed vulnerability occurrences Reviewing the Threat Origins Reviewing the Business Asset Groups Reviewing attacks Check whether the problem is access-related Workflow The basic workflow to identify the critical issues is: 1 Review the directly exposed (and second step) vulnerability occurrences to see whether a limited set of high-risk vulnerability occurrences are enabling most of the attacks. Figure 32: Direct and second step vulnerabilities 2 Review the list of high risk Threat Origins to see whether there are specific ones that seem to be causing a great deal of the risk. Figure 33: Top Threat Origins Skybox Risk Control version

88 Skybox Risk Control User s Guide Note: The order of these two steps is not important; they are different starting points for locating the critical issues. If you find the critical issues with one of these steps, you might not need to use the other one. 3 If there are no indications that specific threats or vulnerability occurrences are causing high risk, check the Business Asset Groups (see page 90). You can also check whether the problem is caused by access-related issues, such as an access rule that is letting in too much traffic (see page 92). Reviewing the directly exposed vulnerability occurrences Directly exposed vulnerability occurrences are those that are one step away from a Threat Origin. To review the directly exposed vulnerability occurrences 1 The Vulnerability Occurrences by Threats graph (on the Analytics Center page and on the Exposure Summary page) shows the numbers of directly exposed and second step vulnerability occurrences for each Threat Origin. Click a link in the graph to view the vulnerability occurrences. Figure 34: Direct vulnerabilities for a Threat Origin 2 In the list, select a vulnerability occurrence to view additional information in the Details pane. 3 The Direct Vulnerability Occurrences by Risk graph (on the Summary pages) shows the number of direct vulnerability occurrences for each risk or severity level. Select a specific Threat Origin to view the number of direct vulnerability occurrences for each risk or severity level, and then click a link in the graph to view the vulnerability occurrences. 4 Expand the group of critical or high-risk vulnerability occurrences (if there are any) to view the problematic vulnerability occurrences. Figure 35: Direct vulnerabilities by risk Skybox Risk Control version

89 Chapter 16 Identifying the critical issues 5 In either of these graphs, you can change the filter to include direct vulnerability occurrences or second step vulnerability occurrences. 6 Select a vulnerability occurrence in the table and view additional information about it in the Details pane. Each tab contains a different type of information about the vulnerability occurrence. Some information relates specifically to this vulnerability occurrence, such as the asset and service on which the vulnerability occurrence is found and some is general information about the vulnerability definition, including the CVSS metrics and known solutions for this vulnerability definition. 7 Do one of the following: a) Mitigate the high-risk vulnerability occurrences by opening tickets on them (see page 94). b) Drill down into individual high-risk vulnerability occurrences using the Attack Explorer. Obviously, the vulnerability occurrences must be mitigated, but this step may give you additional information to help in your choice of solutions for them. Note: You can also open vulnerability occurrence tickets from the Attack Explorer. Reviewing the Threat Origins High risk on a small number of Threat Origins may indicate that these Threat Origins are the major cause of risk for your organization. To review the Threat Origins 1 The Top 3 Threat Origins table (on the Analytics Center and Exposure Summary pages) shows risk levels and numbers of vulnerability occurrences for the three Threat Origins that put your organization at the highest risk. Click a link to view further details about one of them. 2 The Attacks tab is shown in the Table pane. You can see all the attacks that can be perpetrated on your organization by this Threat Origin. 3 Select the attack with the highest risk. 4 Right-click the attack and select Attack Explorer. The Attack Explorer opens with the selected attack displayed visually in the Map pane. You can see how many steps it takes to get from the Threat Origin to the destination Business Asset Group and a topological overview of the attack. 5 Look at the width of the arrows in the attack. A wide arrow shows that there are many ways to perform that step. If the arrow of one step is much wider than the others, this often indicates a root cause that is enabling the access. The cause may be: Entities (such as risky services, a vulnerability definition, or a group of assets that need updating) that should be patched or otherwise remediated. An access issue (usually, this is a firewall that is allowing too much access). 6 Select the widest arrow and check the statistics in the Information pane, to check whether anything looks odd. For example, a relatively large number of vulnerability occurrences but a small number of vulnerability definitions or ports could mean that patching the affected services would greatly reduce the risk on your network. After you identify the problem, create the appropriate ticket (see page 94). Skybox Risk Control version

90 Skybox Risk Control User s Guide Reviewing the Business Asset Groups High risk on a small number of Business Asset Groups may indicate that these Business Asset Groups are the major cause of risk for your organization. To review the Business Asset Groups 1 In the tree, select the Exposure node. 2 In the workspace, click the Business Asset Groups tab. For each Business Asset Group in the table, you can see its risk, and how many assets and vulnerability occurrences it has. Note that the vulnerability occurrence count includes all vulnerability occurrences found on any asset of the Business Asset Group, not only the directly exposed ones. 3 In the Table pane, select the Business Asset Group with the highest risk. 4 In the Details pane, click the Attacks tab. 5 Select the attack with the highest risk. 6 Right-click the attack and select Attack Explorer. The Attack Explorer opens with the selected attack displayed visually in the Map pane. You can see how many steps it takes to get from the Threat Origin to the destination Business Asset Group and a topological overview of the attack. 7 Look at the width of the arrows in the attack. A wide arrow shows that there are many ways to perform that step. If the arrow of one step is much wider than the others, this often indicates a root cause that is enabling the access. The cause may be: Entities (such as risky services, a vulnerability definition, or a group of assets that need updating) that should be patched or otherwise remediated. An access issue (usually, this is a firewall that is allowing too much access). 8 Select the widest arrow and check the statistics in the Information pane, to check whether anything looks odd. For example, a relatively large number of vulnerability occurrences but a small number of vulnerability definitions or ports could mean that patching the affected services would greatly reduce the risk on your network. After you identify the problems, create the appropriate ticket (see page 94). Reviewing attacks The Attack Explorer presents information about the assets, services, and vulnerability occurrences in the system, in the context of specific attacks. You use the Attack Explorer to: View potential attacks Drill down into the causes of potential attacks Define strategies to block potential attacks Create tickets Note: The Attack Explorer is not available until you have run attack simulation (exposure analysis) at least once on the model that you are using. The information shown in the Attack Map is based on the analyses performed during attack simulation if you have changed information that might affect the analyses, rerun attack simulation before using the Attack Explorer. Skybox Risk Control version

91 The Attack Explorer consists of three panes: Chapter 16 Identifying the critical issues Information: Initially, the left pane contains information about the entity on which you opened the Attack Explorer. When you select an entity in the Map pane, information about that entity is displayed. There are additional options in this pane that allow you to drill down into the information. Map: The upper right pane contains an Attack Map for the selected attack (or other selected entity). Vulnerabilities: The lower right pane is used to select the vulnerability occurrences for which to create tickets. To open the Attack Explorer 1 In the Exposure workspace, navigate to the entity to view in the Attack Explorer: Threat Origin Business Asset Group Vulnerability occurrence Attack Note: Especially in large models, it is often most useful to open the Attack Explorer on an asset, vulnerability occurrence, or attack. Otherwise, it may be difficult to read the large amount of data shown in the Map pane. 2 Do one of the following: Select the entity and then click at the top of the table (when available, such as for Threat Origins or Business Asset Groups). Right-click the entity and select Advanced > Attack Explorer. The Attack Explorer opens with the selected entity shown in the Map pane and information about the entity shown in the Information pane. Figure 36: Attack Explorer Skybox Risk Control version

92 Skybox Risk Control User s Guide Check whether the problem is access-related In some cases, risk might be caused by unnecessary access on firewalls. This is often easy to spot in the Attack Explorer. A wide arrow from one point (Point A) to another (Point B) shows that there are many ways to access Point B from Point A. The solution might be to mitigate all vulnerability occurrences on Point B, but it could be that the filtering rules on a firewall between Point A and Point B must be more limiting so that the vulnerability occurrences are not directly exposed, thus lowering the risk. To check whether a problem is access-related 1 Open the Attack Explorer on an entity, as specified in Reviewing attacks (on page 90). 2 In the Map pane of the Attack Explorer, right-click a link and select Show Access Route. You might need to drill down to a specific entity within the destination of that link. 3 In the Information pane, check the Access Route to see which firewalls were used. 4 Drill down into the access rules to check for unnecessary access: a) In the Access Route, click a rule link to examine it. The selected rule is highlighted in the Rule Match Details dialog box. b) Check the access rule to see whether it allows unnecessary access. If necessary, double-click the rule to display all of its parameters. Sometimes there are Any-Any rules that must be limited. In other case, access must be limited to specific services. c) Repeat steps a and b until you find the access rule that needs modifying. 5 (Optional) Use the What If model (on page 101) to check whether restricting access by modifying the access rule has the desired effect (fewer attacks using the same attack path). 6 Create a ticket (see page 94) on a vulnerability occurrence on Point B that is affected by this access rule. Typically, in the Possible Solutions field, select Block or User-Defined, and (if necessary) use the User Comments field to explain the problem. Skybox Risk Control version

93 Chapter 17 Remediation After you have found a critical issue, the next steps are: Validate the vulnerability occurrences: check if they actually reside on the assets and pose a threat; that they were not falsely reported and are not already protected by another means. When necessary, mark vulnerability occurrences as Ignored. Start the remediation process by issuing the necessary tickets. In this chapter Marking vulnerability occurrences as ignored Mitigating critical vulnerability occurrences Creating tickets manually Updating the model after fixing vulnerability occurrences Using the What If model to test changes Marking vulnerability occurrences as ignored If a vulnerability occurrence that is causing risk in the model meets any of the following qualifications, you can specify not to use the vulnerability occurrence during risk analysis: Your organization is aware of the vulnerability occurrence s risk, but has decided to accept this risk for whatever reasons Your organization has decided that the vulnerability occurrence is not important in risk analysis The vulnerability occurrence does not exist (that is, incomplete scanner information caused Skybox View to define a service as vulnerable when it really is not vulnerable) To indicate that a vulnerability occurrence not be used during risk analysis, mark it as ignored. Note: To see changes in the risk values after marking vulnerability occurrences as ignored, rerun the Analyze Exposure task. To mark a vulnerability occurrence as ignored from the Attack Explorer 1 Select the vulnerability occurrence in the Vulnerabilities pane. 2 Click the appropriate icon: : Mark as ignored because the vulnerability occurrence does not exist : Mark as ignored because the vulnerability occurrence is not important : Mark as ignored because the risk of the vulnerability occurrence is accepted by your organization 3 Click Apply to commit the new vulnerability occurrence status to the model. Skybox Risk Control version

94 Skybox Risk Control User s Guide To mark a vulnerability occurrence as ignored from the Manager 1 Select the vulnerability occurrence in the Table pane or in the Details pane. 2 Right-click the vulnerability occurrence and select Change Status. 3 In the drop-down list of statuses, select Ignored and click OK. 4 Select the reason for ignoring the vulnerability occurrence and click OK. Mitigating critical vulnerability occurrences After you validate a vulnerability occurrence and decide it is important, you have a better idea what type of fix is necessary. You can mitigate critical vulnerability occurrences by: Patching or upgrading the vulnerable service Removing the vulnerable service if it is not needed on the vulnerable asset Changing access on the firewalls so that the vulnerability occurrence is not accessible In most organizations, especially large ones, the people who identify the critical issues are not the same as those who fix the issues. In Skybox View, the first step of mitigation is to assign tickets to the appropriate staff members to make them aware of the problem. A ticket can include a suggested solution of how to fix the problem, such as a specific patch to apply. Creating tickets manually Tickets in Skybox View represent action items that must be carried out in your corporate network. Once you ascertain the critical issues, you can create tickets and assign them to the appropriate staff members. Ticket types You can create tickets for: Vulnerability occurrences Vulnerability occurrence tickets are vulnerability occurrence-specific. They may include a proposed solution for remediating the vulnerability occurrence. Vulnerability definitions Vulnerability definition tickets are not vulnerability occurrence-specific. The scope of a vulnerability definition ticket can include all vulnerability occurrences of a specific vulnerability definition or a particular group of vulnerability occurrences, such as all the vulnerability occurrences of a specific vulnerability definition at a specific location. Like vulnerability occurrence tickets, they may include a proposed solution for remediation. Business Asset Groups Business Asset Group tickets indicate that the risk of the specified Business Asset Group is too high. These tickets are less useful for specific issues and are usually used as alerts. Each ticket is assigned to an owner (someone who is responsible for making sure that the action item is carried out); you can assign each ticket a due date so that you can track its status. Select an owner from the appropriate team: in most organizations, the IT Systems team is in charge of solutions involving specific vulnerability occurrences (such as patches and upgrades), while the Network Operations team is in charge of access-related solutions (such as fixing access rules). Note: Tickets can only be assigned to Skybox View users. If necessary, set up ticket phases, which define different steps for remediation (see Defining ticket phases, in the Skybox View Reference Guide). Skybox Risk Control version

95 Chapter 17 Remediation Creating tickets To create a ticket from the Manager window In the Table pane, right-click the selected entity and then select Create Ticket or Create Vulnerability Definition Ticket. For information about creating: A single vulnerability occurrence, see Creating tickets for a single vulnerability occurrence (on page 96) You can also create a vulnerability definition ticket for the vulnerability occurrence's vulnerability definition. For example, when a patch is created that solves vulnerability occurrences with a Vulnerability Dictionary ID of 0034, you can use one vulnerability occurrence to create a vulnerability definition ticket that covers all vulnerability occurrences of that vulnerability definition (see Creating vulnerability definition tickets (on page 99)). Multiple vulnerability occurrences, see Creating vulnerability definition tickets (on page 99) A set of separate vulnerability occurrence tickets, see Creating sets of tickets for multiple vulnerability occurrences (on page 100) For information about creating tickets from the Attack Explorer, see Creating vulnerability occurrence tickets in the Attack Explorer (on page 97). Note: Tickets can be created automatically using tasks (see Automating tickets (on page 104)). Viewing tickets Once a ticket is created, you can view it and manage it from the Tickets tree. Skybox Risk Control version

96 Skybox Risk Control User s Guide Creating tickets for a single vulnerability occurrence To create a ticket for a single vulnerability occurrence 1 In the Tree pane, open a vulnerability occurrences analysis for which the results in the Table pane are vulnerability occurrences. 2 In the Table pane, right-click the vulnerability occurrence for which you are creating a ticket and select Create Ticket. Figure 37: New Vulnerability Ticket 3 Fill in the fields according to the table in Vulnerability occurrence ticket parameters, in the Skybox View Reference Guide. Some fields are filled with default values and others are optional, but you must select an owner for the ticket. 4 To recommend a solution to the ticket owner: a) Click the Solutions tab. The list shows solutions from the Vulnerability Dictionary and may also include proprietary solutions prepared in your organization. b) Select a solution or click Add Custom to specify a proprietary solution. The ticket is created and added to the list of new tickets for the selected owner. Skybox Risk Control version

97 Chapter 17 Remediation Creating vulnerability occurrence tickets in the Attack Explorer To create vulnerability occurrence tickets in the Attack Explorer 1 In the Map pane, find a set of links such that by blocking them all you block the attacks on the Business Asset Group. For example, if you are most concerned about a specific Threat Origin, find the set of links that blocks all attacks from that Threat Origin. 2 Examine the entry (or exit) vulnerability occurrences associated with these links. The entry vulnerability occurrences associated with a link are vulnerability occurrences in the link s destination that can be exploited directly from the link s source. The exit vulnerability occurrences associated with a link are vulnerability occurrences in the link s source whose exploitation enables access to the link s destination in an attack. To list a link s entry vulnerability occurrences in the Vulnerability Occurrences pane, doubleclick the link in the Map pane or right-click the link in the Map pane and select List Entry Vulnerability Occurrences. To list a link s exit vulnerability occurrences in the Vulnerability Occurrences pane, right-click the link in the Map pane and select List Exit Vulnerability Occurrences. The selected vulnerability occurrences appear in the Vulnerability Occurrences pane, in the Attack Steps tab. Vulnerability occurrences that have vulnerability occurrence tickets are listed, but you cannot select them. As they already have tickets, you cannot create new tickets for them in the Attack Explorer, although you can create new tickets for them manually (see page 94). Tip: To view the Access Route of a specific link, right-click the link and select Explain Access. 3 Block each link by marking its entry or exit vulnerability occurrences as To be Solved (see page 98). 4 Review the To be Solved vulnerability occurrences and create tickets (see page 98). At this point, the requests for new tickets exist only in the Attack Explorer. 5 Click OK to save your remediation decisions (assigned tickets, and vulnerability occurrences marked as Ignored) to the database. A separate ticket is generated for each of the selected vulnerability occurrences. Skybox Risk Control version

98 Skybox Risk Control User s Guide Example In the following Attack Map, blocking one of (a) links 1, 3, and 4; (b) links 2, 3, and 4; or (c) link 5 blocks the possible attacks on the selected Business Asset Group (named Finance Application). Figure 38: Possible link sets in the Attack Explorer Marking vulnerability occurrences To mark vulnerability occurrences as To be Solved In the Vulnerability Occurrences pane, mark each vulnerability occurrence as To be Solved by selecting its S check box. After vulnerability occurrences are marked as To be Solved, nodes that can no longer participate in attacks become gray in the upper pane, representing the after fix situation. Creating tickets You can create tickets for a single set of entry or exit vulnerability occurrences directly from the Vulnerabilities pane and go on to the next set of vulnerability occurrences. Or, in each set, select the vulnerability occurrences to use to create tickets and click the Selected Solutions tab to show the To be Solved vulnerability occurrences. Note: Each time you select a link in the Map pane and list its vulnerability occurrences, the selected vulnerability occurrences overwrite the previous vulnerability occurrences in the Vulnerabilities tab of the Vulnerabilities and solutions pane. However, the Selected Solutions tab contains an aggregation of all vulnerability occurrences marked as To be Solved until the link is selected. To review vulnerability occurrences and create tickets 1 In the Vulnerability Occurrences pane (Attack Steps tab or Selected Solutions tab, as appropriate) show the To be Solved vulnerability occurrences. 2 Select vulnerability occurrences for which you want to assign a ticket with the same solution (or with no suggested solution) to a specific owner. Note: When assigning a ticket, either recommend a specific solution or leave the solution to the assigned owner. 3 Click. 4 Fill in the fields of the ticket. If you are creating tickets for several vulnerability occurrences, type a string in the Title Prefix field. This is prepended to the vulnerability occurrence name and location to create the title of the vulnerability occurrence ticket. Skybox Risk Control version

99 Chapter 17 Remediation In the User Comments field, explain to the ticket owner how the vulnerability occurrences should be mitigated. For additional information about the ticket fields, see Vulnerability occurrence ticket parameters, in the Skybox View Reference Guide. 5 Click OK to create the ticket. Note: Tickets created in the Attack Explorer are not added to the model until you click Apply (or click OK close the Attack Explorer). 6 Repeat steps 2 through 7 until all necessary tickets are created. 7 Do one of the following: Click Apply to save the tickets (and vulnerability occurrences you have marked for ignoring) without closing the Attack Explorer. Click OK to save your changes and close the Attack Explorer. Creating vulnerability definition tickets You can create a ticket for a vulnerability definition rather than a specific vulnerability occurrence. For example, if a new security patch is released for a specific vulnerability definition, you could create a vulnerability definition ticket rather than creating a ticket for each single vulnerability occurrence. You can create a vulnerability definition ticket for specific vulnerability occurrences of the vulnerability definition, such as all vulnerability occurrences of that vulnerability definition in London. To create a vulnerability definition ticket for specific vulnerability occurrences 1 In the Risk Control tree, open a vulnerability occurrence analysis (under Analytics Center > Analyses > Public Analyses > Vulnerability Occurrences) for which the results in the Table pane are vulnerability occurrences (rather than vulnerability definitions). 2 In the Table pane, select vulnerability occurrences of the vulnerability definition for which you are creating the ticket. 3 Right-click the vulnerability occurrences and select Create Vulnerability Definition Ticket. 4 In the New Vulnerability Definition Ticket dialog box: a) Fill in the fields according to the table in the Vulnerability definition ticket parameters topic in the Skybox View Reference Guide. The selected vulnerability occurrences are the default Network Scope for the new ticket. b) To recommend a solution for the vulnerability occurrences: 1. Click the Solutions tab. The list shows solutions from the Skybox View Vulnerability Dictionary and may also include proprietary solutions prepared in your organization. 2. Select a solution or click Add Custom to specify a proprietary solution. You can add multiple custom solutions if necessary. c) Click OK. The ticket is created and added to the list of new tickets for the selected owner. Skybox Risk Control version

100 Skybox Risk Control User s Guide To create a ticket for all vulnerability occurrences of the vulnerability definition 1 In the Risk Control tree, select Analytics Center > Analyses > Public Analyses > Vulnerabilities, and then select an analysis that displays vulnerability definitions, such as Miscellaneous > Vulnerabilities by Definition or Dictionary > Vulnerability Dictionary. 2 In the Table pane, right-click the vulnerability definition for which you are creating a ticket and select Create Ticket. 3 In the New Vulnerability Definition Ticket dialog box: a) Fill in the fields according to the table in the Vulnerability definition ticket parameters topic in the Skybox View Reference Guide. The default Network Scope for the new ticket is all vulnerability occurrences of the selected vulnerability definition. b) To recommend a solution for the vulnerability occurrences: 1. Click the Solutions tab. The list shows solutions from the Skybox View Vulnerability Dictionary and may also include proprietary solutions prepared in your organization. 2. Select a solution or click Add Custom to specify a proprietary solution. c) Click OK. The ticket is created and added to the list of new tickets for the selected owner. Creating sets of tickets for multiple vulnerability occurrences You can select a number of vulnerability occurrences and create separate but similar tickets for each one. The ticket names all have the same prefix (which you define), followed by the name of the vulnerability definition and the IP address of its asset. Note: This is not the same as creating one vulnerability definition ticket for multiple vulnerability occurrences of the same vulnerability definition (see Creating vulnerability definition tickets (on page 99)). Each set of tickets you create has one owner. If you want a ticket to have a different owner, define it separately. For example, if Joe is in charge of vulnerability occurrences of a certain vulnerability definition in one part of your network and Jane is in charge of similar vulnerability occurrences in another part of your network, you define one set of tickets for Joe and another for Jane, even if there is no other reason to split these vulnerability occurrences. To create a set of tickets for multiple vulnerability occurrences 1 In the Tree pane do one of the following: Select the Vulnerability Occurrences node of the Model tree. Open a vulnerability occurrences analysis for which the results in the Table pane are vulnerability occurrences (rather than vulnerability definitions). The Table pane displays the appropriate vulnerability occurrences. 2 In the Table pane, sort the list of vulnerability occurrences to make it easier to select a specific set of them. 3 Select the vulnerability occurrences. Right-click in the selection and select Create Ticket. In the New Vulnerability Occurrence Ticket dialog box, the field label Title is replaced by Title Prefix. The title of each ticket consists of the prefix that you type here, followed by the name of the vulnerability definition and the IP address of its asset. (In the preceding example, you could use the prefix Jane for one set and Joe for the other set.) Skybox Risk Control version

101 Chapter 17 Remediation 4 Fill in the fields according to the table in Vulnerability occurrence ticket parameters, in the Skybox View Reference Guide. 5 To recommend a particular solution to the owner for all of the vulnerability occurrences: a) Click the Solutions tab. The list shows solutions from the Skybox View Vulnerability Dictionary and may also include proprietary solutions prepared in your organization. b) Select a solution or click Add Custom to specify a proprietary solution. 6 Click OK. The tickets are created and added to the list of new tickets for the selected owner. Updating the model after fixing vulnerability occurrences When a vulnerability occurrence is fixed in the actual network, the model must be updated to reflect the new life-cycle status of the vulnerability occurrence and attack simulation run on the new data. Otherwise, the analysis is no longer accurate. There are various ways to update the model: Wait for the next scanner task or import task to detect the changes. Run a selective scan to detect or verify whether vulnerability occurrences marked as Fixed are actually fixed. Manually mark vulnerability occurrences as Fixed in the model based on approval from staff members. This is useful if no import or collection of network data is planned in the near future. To mark a vulnerability occurrence as Fixed 1 Find the vulnerability occurrence in the Table pane of an analysis (or the Vulnerability Occurrences node of the Model tree). 2 Right-click the vulnerability occurrence and select Change Status. 3 Change the status to Fixed and click OK. 4 In the confirmation dialog box, select a fixed status (I m sure the vulnerability occurrence was fixed or The vulnerability occurrence was probably fixed) and click OK. If you select The vulnerability occurrence was probably fixed, the vulnerability occurrence is checked during the next vulnerability occurrence scan (which changes the status to Found if the vulnerability occurrence is rediscovered). Until then, it is considered Fixed and is not used for attack simulation. Using the What If model to test changes Skybox View supports a What If model, where you can simulate the effect of solutions before applying them to the real corporate network. You can use this model to test planned changes to architecture or to firewall and router configurations. The What If model allows you to simulate the changes to your system and then check the potential effects on your system without making the changes. You can analyze potential risks from the changes without causing any harm to your system; the changes you make to the What If model do not affect the Live model or your corporate network. To use the What If model for testing 1 Do one of the following: Create a What If model and open it (Select File > Models > Create Model. In the dialog box, select Live as the Source Model and What If as the Target Model and then select Switch to target model after creation). Skybox Risk Control version

102 Skybox Risk Control User s Guide Open the What If model (select What If from the drop-down list of models on the toolbar). 2 Make changes to the What If model. 3 Run the Analyze Exposure task on the What If model. 4 Check the analyses to see whether you get the desired results. If so, recommend that these network or security changes be made in your corporate network. If the changes relate to vulnerability occurrences or Business Asset Groups, switch to the Live model and open the appropriate tickets there. 5 You can return to the Live model at any time to view the current security situation in your network. Skybox View saves the current situation of the What If model until you create a new What If model. Skybox Risk Control version

103 Chapter 18 Continuous risk management The following sections explain the process of continuous risk management using Skybox View. In this chapter Overview of continuous usage Attack simulation for continuous usage Monitoring the risk status Automating tickets Tickets and workflow Model maintenance Overview of continuous usage This chapter explains how to use Skybox View on a proactive (continuous and automatic) basis to ensure the continued security of your corporate network, rather than checking and securing the system on a reactive basis every several months. The benefits of working in this manner are: A shorter window of exposure to new vulnerability definitions and worms A continuous view of the security status of your corporate network A small amount of effort every day or week, compared to a large project on a quarterly or semiannual basis Attack simulation for continuous usage Run the Analyze Exposure task: After new data is added to the model, for the new data to influence the risk After other changes to the model, such as dictionary updates or aging Include this task in every task sequence that involves changes to the model, after the tasks that make changes. Monitoring the risk status When new data is added to the model, you can monitor the current risk status using any of the following methods: Review risk metrics to identify current security problems in the corporate network You can view risk metrics from the Exposure Summary page or from any other Exposure page where risk is displayed Skybox Risk Control version

104 Skybox Risk Control User s Guide View risk trends as a way of understanding current changes to the corporate network in a broader context You can view risk trends for vulnerability occurrences in the Trend of Direct Vulnerability Occurrences graph on the Exposure Summary page. For Threat Origins, the Top 3 Threat Origins table includes the delta values for direct and second-step vulnerability occurrences from the current number of vulnerability occurrences to the previous one (from the last time that exposure was analyzed). Check whether new assets or services were added to the corporate network Check whether new vulnerability occurrences were detected Checking for new entities New assets may be added to the corporate network, new services may be added on any asset, and new vulnerability occurrences may be detected on these new assets and services, and on existing assets. If these entities cause high risk or if the vulnerability occurrences are directly exposed, they affect the exposure results. Skybox View provides analyses that allow you to ascertain quickly whether new entities were added to the system and to view additional information about them. Use the following analyses to identify new entities: In the Model Analyses > New Entities node of the Model tree: New Assets: Recently discovered assets Assets with New Services: Existing assets with newly discovered services In Risk Control > Analytics Center > Analyses > Public Analyses > Vulnerabilities > New Vulnerability Occurrences: New Vulnerability Occurrences: Recently discovered vulnerability occurrences Uncataloged Vulnerability Occurrences: Vulnerability occurrences detected by scanners but not yet modeled in Skybox View Note: Keeping your Vulnerability Dictionary up-to-date usually eliminates most uncataloged vulnerability occurrences. You can add new analyses or change existing ones. For example, to see what changed in several major locations separately, make copies of the relevant analysis, change their names, and change the network scope. Automating tickets This section explains how to set up and use automatic ticketing and alerts in Skybox View. Note: You can integrate Skybox View with other ticketing systems (see the Tickets API chapter in the Skybox View Developer s Guide or contact Skybox View technical support (see page 8)). Setting up ticket automation This section explains how to set up ticket automation, including ticket rules and ticket rule alerts. Ticket rules A ticket rule is a rule that defines the conditions under which new tickets of a specific ticket type are created automatically. Tickets are not created on a continuous basis whenever the conditions of a ticket rule are met, but only when a Tickets Auto Generation task is run. Several predefined ticket rules are included as part of the Skybox View installation, including: High Risk Asset: Used to create tickets for Business Asset Groups that have become high risk (that is, their priority has gone up to High or Critical). Skybox Risk Control version

105 Chapter 18 Continuous risk management New Direct Externally Exposed Vulnerability Occurrences: Used to create tickets for new directly exposed vulnerability occurrences and for existing vulnerability occurrences that have become directly exposed. Vulnerability Definitions Subject to Worm Attacks: Used to create tickets for vulnerability definitions that have many vulnerability occurrences in the corporate network. These vulnerability definitions are prone to exploitation by attackers and worms. Ticket rule alerts You can define alerts for each ticket rule. A ticket rule alert is a message about tickets that is sent to a specified recipient: a user, an SNMP management system, or syslog. Ticket rule alerts are also exportable to third-party ticket-tracking and workflow systems. Alerts are sent when new tickets are created using the ticket rule. Ticket rule alerts can be sent via any of the following media: Alerts can be sent to specified registered Skybox View users Recipients of alerts (people and external systems) must be registered Skybox View users. All types of users may receive alerts, but users of type Recipient can only view alerts; they have no access to Skybox View and they cannot view the tickets therein. SNMP: Alerts are sent to an external SNMP management system as SNMP traps. Syslog: Alerts are sent as messages to the syslog server. Each ticket rule may include alerts. For example, if two people should know about the Business Asset Groups covered by a ticket rule, you can define an alert for each of them. If alerts should be sent to one person and to the syslog server, you can define one alert and one syslog alert. Note: Skybox View must be configured to send alerts (see Configuring SNMP alerts and Configuring syslog alerts, in the Skybox View Installation and Administration Guide). Alerts are sent: When alerts are defined for a ticket rule, only one message is sent per alert recipient even if there are multiple tickets generated for the rule. For the other media types, a separate alert message is sent for each ticket generated by the rule. Note: Admins can change the content of ticket rule alerts (see Changing the content of ticket rule alerts, in the Skybox View Reference Guide). Creating ticket rules Skybox View includes several predefined ticket rules; you can create additional ticket rules or edit existing ones. To be notified of some types of security problems without having to manage the whole ticketing process, create specific ticket rules for this purpose (see page 106) or edit existing ones. To create a ticket rule 1 Select Tools > Administrative Tools > Ticket Rules. 2 On the toolbar of the Skybox View Admin window, click. 3 In the New Ticket Rule dialog box, fill in the fields in the General pane. When you select a Ticket Type, the Parameters pane displays the fields for that ticket type. For parameter definitions, see the Ticket rules section in the Skybox View Reference Guide. Each type of ticket rule has filters that define the entities that have tickets created for them by this rule. A ticket is created for an entity only if it matches every filter for its ticket type. Skybox Risk Control version

106 Skybox Risk Control User s Guide 4 (Optional) Set up the ticket rule to send alerts when tickets are created. 5 Click OK. The new ticket rule is added to the list of ticket rules. Issuing alerts without tickets In some cases, you might want to send alerts for security problems to a specific user or to the system log without managing the whole ticketing process. In these cases, you can create a ticket rule that only sends an alert. To create alerts without tickets 1 In the desired automatic ticket rule, select Alert Only. 2 In the Alerts tab, define at least one alert for this ticket rule. Note: These ticket rules create tickets for tracking purposes, but the tickets have a status of Closed, rather than New, and do not appear in analyses that show new tickets. However, you can track them in Skybox View using tickets analyses such as Done Tickets > Closed (or Recently Closed). Generating tickets from ticket rules Usually, tickets are generated from ticket rules using Tickets Auto Generation tasks, such as the predefined Create Tickets task. These tasks generate tickets for all ticket rules. If necessary, an Admin can manually generate tickets for a specific ticket rule. To generate tickets manually from a ticket rule 1 Select Tools > Administrative Tools > Ticket Rules to open the Skybox View Admin window. 2 In the Table pane, right-click the ticket rule to run and select Generate Tickets. Skybox View searches the model to see whether there are any entities (assets, Business Asset Groups, vulnerability definitions, or vulnerability occurrences) that meet the ticket rule requirements. If there are, it creates a ticket for each one. What happens during ticket generation Each time that you generate tickets (using a ticket task or Generate Tickets for a specific ticket rule), Skybox View: Evaluates all relevant ticket rules (either all ticket rules or the specific ticket rule that you selected) Creates new tickets Updates tickets that satisfy ticket rule conditions Closes tickets that no longer meet the conditions of the rule that caused their creation Creates alerts for new tickets, if necessary The following changes can cause a ticket rule condition to no longer be met: Changes to the model Changes to the ticket rule In these cases, when ticket generation is complete, all tickets previously generated by a rule that no longer satisfy the rule s conditions are closed. Tickets and workflow Tickets in Skybox View represent action items that must be carried out in your corporate network. They can be created manually or from ticket rules that are configured to create tickets for entities on which specified thresholds are reached. Skybox Risk Control version

107 Chapter 18 Continuous risk management Managing Skybox View tickets is a way of ensuring that all security issues found by Skybox View are resolved properly and within the designated time frame. Note: You can set up ticket phases, which define different steps for remediation (see Defining ticket phases, in the Skybox View Reference Guide). Monitoring tickets To make sure that all tickets are handled properly, monitor the status of tickets. Verifying that tickets are being acted on You can check the status of tickets using: Tickets reports, such as the Overdue Tickets Details report. Tickets analyses, such as the All Tickets > Open Tickets > In Progress analysis. Overdue tickets have a status of New or In Progress but have passed their assigned due date. You can contact the ticket owners to find out why they have not handled the ticket. Because the ticketing workflow provides a history of compliance to security requirements, you should update the status of tickets to reflect the status of the solutions applied. Working with tickets Existing tickets can be: Viewed Assigned to different owners Edited Changed to a different status Closed To view and handle individual tickets, select the ticketed entity in the appropriate workspace and access the ticket in the Tickets tab of the Details pane, or by work in the Tickets workspace. You view and handle groups of tickets in the Tickets workspace. For example, to view all tickets created within the past week, use the Public Tickets > All Tickets > Open Tickets > New analysis. Viewing tickets Folders in the Tickets tree contain analyses related to tickets. The top-level nodes of the Tickets tree are: Public Ticket Analyses: Contains the tickets analyses available to everyone who logs in to the Manager. The All Tickets folder contains tickets in the system distributed by status. The My Tickets folder contains only tickets that are owned by the logged-in user. Private Ticket Analyses: Contains analyses that are not visible to other users of the system. Use this folder to create your own tickets analyses. You can view additional parameters about a specific ticket: Select the ticket in the Table pane and view the information in the Details pane. Double-click the ticket in the Table pane to open it. Skybox Risk Control version

108 Skybox Risk Control User s Guide Searching for tickets You can search for tickets on a one-time basis, without creating an analysis for them. The search is based on a match between a text string and one or all of the following ticket fields: Title ID User Comments Status Priority Owner Solution Name To search for tickets 1 With the Ticket workspace open, click (on the toolbar). 2 In the Search panel, type a string into the Find What field. 3 In the Look In field, select the ticket field in which to search for the string. 4 Click. Tickets that include the search string in the specified field are listed in the Table pane. Assigning tickets to different owners You can assign a ticket to a different owner whenever necessary, such as when you have made changes and must send the ticket to a different team. To assign a ticket to a different owner 1 In the Table pane (or the Details pane), right-click the ticket and select Reassign. 2 Select a new owner and click OK. Changing ticket statuses Skybox View supports the following predefined ticket statuses: New: This is the default status for all newly created tickets. In Progress: The owner has seen the ticket and is in the process of handling it. Ignored: The ticket is not important and the owner has chosen to ignore it. This status is used, for example, if the vulnerability occurrence for which the ticket was created is a false positive or if the issue is not really a problem. Rejected: While the problem for which the ticket was issued does exist, the solution is not appropriate or cannot be applied. This can happen, for example, if the suggested solution is to change a specific access rule to block access, but changing that rule also blocks access to an important application. Resolved: The problem was handled by its user, but the fix is not verified. Closed: The task was completed and verified. This is the final ticket status. Admins can define up to five custom ticket statuses in Skybox View, (see Custom Ticket Statuses, in the Skybox View Installation and Administration Guide). With the exception of automatically created tickets, which are automatically closed when their conditions are no longer met, ticket status does not change automatically. It must be changed manually by the ticket owner or by an Admin. Skybox Risk Control version

109 To change the status of a ticket 1 Find an analysis containing the ticket. 2 In the Table pane, right-click the ticket and select Change Status. 3 In the dialog box, select the new status for the ticket and then click OK. Chapter 18 Continuous risk management The status of the ticket changes. Although the ticket may no longer match the current analysis (for example, a ticket whose status was changed from New to In Progress no longer matches the criteria of the New analysis), it is listed in the old analysis until you refresh the screen or navigate away from the current analysis. Note: Changing the status of a vulnerability occurrence ticket to Resolved or Closed changes the status of the vulnerability occurrence in the model to Fixed and the vulnerability occurrence is no longer used for attack simulation (see Closing vulnerability occurrence tickets (on page 109)). Closing tickets You can close tickets manually or automatically. Closing tickets manually You close a ticket by changing its status to Closed. When you close a vulnerability occurrence ticket, the status of the vulnerability occurrence changes in the model. For additional information, see Closing vulnerability occurrence tickets (on page 109). When you delete a ticket rule, you are asked whether to close all tickets created by the rule or leave them unchanged. Important: When you finish working with a ticket, close it; if you delete a ticket, you lose the history of the problem that caused the ticket. Automatic closure Tickets are closed automatically when: An automatically created ticket no longer meets the conditions of the rule that generated it The ticketed entity (that is, the Business Asset Group or vulnerability occurrence) is deleted When vulnerability occurrence tickets are closed automatically, they do not affect the vulnerability occurrences for which they were generated. Closing vulnerability occurrence tickets In general, tickets affect entities in the model only when the ticket owner implements the changes. However, some changes to the status of a vulnerability occurrence ticket affect the vulnerability occurrence for which the ticket was opened. Note: By default, closing vulnerability occurrence tickets affects the vulnerability occurrence; Admins can configure Skybox View so that closing the tickets does not affect the vulnerability occurrences. When you manually change the status of a vulnerability occurrence ticket to Resolved, the status of the vulnerability occurrence changes to Fixed. These vulnerability occurrences are checked during the next scan to confirm that they are really fixed. When you manually close a vulnerability occurrence ticket, the status of the vulnerability occurrence changes to Fixed. Fixed vulnerability occurrences are not used for attack simulation. Skybox Risk Control version

110 Skybox Risk Control User s Guide If you select a solution for a vulnerability occurrence ticket, when you close the ticket the model changes according to the solution that you selected: Upgrade: The service version found by the scanner is overwritten with the version supplied in the solution. Patch: The patch is recorded as applied on the asset. Remove: The service is marked as down. For example, if the selected solution is to upgrade the service on which the vulnerability occurrence is found, the service is upgraded on the asset in the model. Tickets that are closed automatically do not change the model or affect the vulnerability occurrences for which they were created. Managing tickets analyses You can edit or copy analyses in the Tickets tree to meet your needs. You can also create analyses from scratch and delete analyses that are not relevant. You can sort the results of a tickets analysis by various parameters, such as status, priority, ticket type, and ticket owner. You can display additional columns of information (such as operating system, service, or ticket rule that created the ticket) or hide columns to focus on particular aspects of the analysis. For information about the parameters of tickets analyses, see Tickets analyses, in the Skybox View Reference Guide. Note: Users can create and edit analyses only in the Private Ticket Analyses folder. When working with ticket phases, you can create a separate analysis for each phase. Model maintenance You can automate the process of maintaining and updating the model, including: Model updates Data monitoring General maintenance (such as saving and loading backup versions of the model) For additional information, see Model maintenance (on page 124). You can schedule reports to run on an automated basis and sent to the desired recipients (see the Automating reports topic in the Skybox View Reference Guide). Skybox Risk Control version

111 Part III: Continuous usage This part explains how to work with Skybox Risk Control on a continuous basis.

112 Chapter 19 Using tasks for automation Scheduled tasks and task sequences are used in Skybox View to automate various processes, such as data updates, model maintenance, and reports. This chapter explains how to work with task sequences and how to schedule tasks and task sequences. For information about using tasks and about each specific task type, see the Tasks section of the Skybox View Reference Guide. Note: Only Admins and Users can work with tasks. Admins can work with all tasks; Users can work with a limited range of tasks, including tasks that generate reports, tickets, and CSV files, and tasks that analyze data. In this chapter Task sequences Scheduling tasks and task sequences Task groups Monitoring task results Task sequences You can define task sequences, where each task in the sequence runs as soon as a previous task ends. This is useful when you often want to run a specific set of tasks in a particular order. You can use separate task sequences for different purposes (such as data collection and maintenance), different parts of the system, and different frequencies (once a day, once a week, and once a month). Creating task sequences You create a task sequence by creating an ordered set of tasks where each task in the sequence depends on the outcome of another task. If the outcome of the previous task (the triggering task) is not exactly what you specified, the next task is not launched. For example, you can make the Analyze Simulate Attacks task dependent on a full scan completing with a status of Success: if the full scan completes with any errors that prevent it from having the Success status, the Analyze Simulate Attacks task is not launched. Subsequent tasks that depend on a task that was not launched are also not launched. If, in the previous example, the Generate Risks Details Report task is the next task in the sequence and it is scheduled to run after the Analyze Simulate Attacks task completes, it does not run. Skybox Risk Control version

113 Chapter 19 Using tasks for automation To create a task sequence 1 On the Operational Console toolbar, click. 2 Type a Name for the sequence. 3 In the Sequence Tasks pane, click Add. Figure 39: New Task Sequence dialog box 4 In the Add Task dialog box, select a task to add to the sequence and click OK. This task is added as the first task in the task sequence. 5 Add additional tasks to the task sequence: Note: A single task can only be used once per task sequence. However, you can use different tasks of the same task type in a task sequence. Skybox Risk Control version

114 Skybox Risk Control User s Guide a) Click Add. The Add Task dialog box now includes additional fields to create a dependency on a previous task. Figure 40: New Sequence Task dialog box (not for first task) b) Select a task to add to the sequence. A default dependency is created, so that this task is run after the previous task finishes with one of the specified exit codes. c) To change the triggering task, select a different task in the Depends on Task field. d) To change the exit codes of the triggering task, click the Browse button next to the Depends on Exit Codes field. If the triggering task ends with a different exit code, the dependent task is not triggered. e) Click OK. 6 Click OK. The new dependency is added to the sequence for this task. Viewing and editing task sequences To view task sequences 1 In the Operational Console tree, select Tasks > Task Sequences. 2 Select a task sequence. Tasks in the sequence are listed in the Table pane and general information or messages from the last run of the selected task in the Details pane. Skybox Risk Control version

115 Editing task sequences Chapter 19 Using tasks for automation You can add and remove tasks from a sequence and change the order of the tasks in the sequence and the exit conditions for the triggering task. To edit a task sequence Right-click the task sequence in the tree and select Properties. Scheduling tasks and task sequences You can define a task or a task sequence so that it runs at scheduled times, such as on Sundays at 5 p.m. and Wednesdays at 4 a.m., on the 15th and 28th of every month, or every 15 minutes. Although tasks and sequences are usually scheduled to run on the Live model, you can schedule them to run on any model. To schedule a task or task sequence 1 Navigate to the task or sequence in the Operational Console tree. 2 Right-click the desired task or sequence and select Properties. 3 In the <Task_name> Properties dialog box, click the Schedule tab. 4 For each desired schedule (such as the first of every month or every Sunday): a) Click Add. Figure 41: New Task Schedule dialog box b) Select a time slice (hourly, daily, weekly, monthly, or yearly) and fill in the corresponding fields, such as at which hour or on which day of the week. c) If the task is to run a limited number of times, select End after and type the number of times that you want the task to run. d) By default, all tasks are scheduled to run on the Live model. To run the task on a different model, select the desired model in the Model drop-down list. e) Click OK. The new schedule is added to the list of schedules for this task. Skybox Risk Control version

116 Skybox Risk Control User s Guide 5 Click OK. Note: If auto-launch is not enabled for a task, it does not run on its specified schedules. However, it does run in a task sequence if it is part of one. To view scheduled tasks and sequences Task groups In the Operational Console tree, select Tasks > Schedules. A list of schedules appears in the Table pane and the scheduled entities are listed in separate tabs (Tasks and Sequences) in the Details pane. You can group a set of tasks together so that you can view them separately from the other tasks, in their own folder. To create a task group 1 On the Operational Console tree, right-click Task Groups. 2 In the New Task Group dialog box: a) Type a name for the group. b) In the User Comments field, type a description of the group. c) To select tasks to include in this group, click the Browse button next to the Tasks field. d) Click OK. A folder for this group is added under the Task Groups node. Note: Task groups are for viewing purposes only. You cannot launch or schedule the task group, only the individual tasks within it. To create a set of tasks that run together, use a task sequence (see page 112). Monitoring task results Task messages After running a task, you can check the task results to make sure that the outcome is what you expected. For example, after updating firewall configurations (using tasks), check the task results to confirm that all data was properly imported into Skybox View. Check for failed tasks; if a task failed, find out why it failed, make the necessary changes, and rerun the update task for the failed firewall. You can see a list of tasks that failed in the Operational Console window, at Tasks > Failed Tasks. For each task, you can see the messages from the task s most recent run. Task alerts You can set up Skybox View to send alerts to various users for failed tasks. To configure task alerts 1 Select Tools > Options > Server Options > Task Settings > Task Alert Settings. 2 Do one of the following in the to field: Type the addresses to which alerts are to be sent. Separate multiple addresses with commas, with no space between the comma and the following address. Skybox Risk Control version

117 Chapter 19 Using tasks for automation Click the Browse button; select Skybox View users who are to receive alerts and add the external addresses of other desired recipients. All alerts are sent to each specified recipient. 3 Modify any of the following as necessary: on: The exit codes on which to send task alerts. The default exit codes for sending alerts are: Error, Fatal, Timeout, and Terminated. Messages Count: The maximum number of messages from the failed task to include in the task alert. The default value is Click OK. Disabling task alerts When recipients are defined, task alerts are sent for each task that meets the defined exit conditions (such as task failure). However, if there are specific tasks for which you do not want to receive task alerts, you can turn of the alerts on a per-task basis. To disable alerts for a specific task 1 Open the task Properties dialog box. 2 In the General tab, select Disable Task Alerts. Skybox Risk Control version

118 Chapter 20 Reports Reports in Skybox View are detailed accounts of specific data in the model, such as high-risk entities, firewall changes, overdue tickets, or top ten entities. You can schedule reports to run at specific times and be sent automatically to specified Skybox View users. In addition to the standard reports (created in PDF, HTML, or RTF), you can also create CSV reports. These are often used by third party applications for further processing. There are several ways to work with reports: Create reports as you are working: Using the shortcut menus found by right-clicking many entities in the Tree pane By saving tables in CSV format Schedule reports via tasks (including Report - Auto Generation tasks and various CSV export tasks) View (and create) reports in the Reports workspace, and customize their content In this chapter Security Metrics reports Risks reports FISMA/NIST and Risk Assessment reports PCI DSS reports Tickets reports Vulnerability Management reports Vulnerabilities reports Exporting data to CSV files Exporting vulnerability occurrence data to Qualys format Security Metrics reports Security Metrics reports are used when working with the Security Metrics feature of Skybox Risk Control. Security Metrics reports contain security metrics information for the selected security metric type (VLI or RLI) and information about: The contribution of vulnerability definitions to the security metrics The contribution of subunits to the security metrics scores Trends These reports are usually used for reviewing security metrics in a specific unit. To avoid information overload, Security Metrics reports can show data about a single unit only or about a unit and its child subunits (one level down). To generate a Security Metrics report, specify the scope (that is, the units to include in the report) and select the security metric type of the report. Skybox Risk Control version

119 Chapter 20 Reports For additional information about Security Metrics reports, see Security Metrics reports, in the Skybox View Reference Guide. Risks reports Risks reports are used when working with the Exposure feature of Skybox Risk Control. Risks reports contain information about any of the following, depending on the scope of the report: The Business Units with the highest potential risk of being compromised. The Business Asset Groups with the highest potential risk of being compromised by attacks and vulnerability occurrences. The Regulations and Business Impacts with the highest potential risk of being compromised. The Threat Origins in your network that impose the highest potential risk on high-value Business Asset Groups. These reports are usually used to highlight the Business Asset Groups with the highest risk and to provide the risk factors that caused the risk on these Business Asset Groups. For additional information about risks reports, see Risks reports, in the Skybox View Reference Guide. Predefined risks reports Skybox View includes the following predefined risks report definitions: Risks Details: Presents details of the top entities of each selected entity type (for example, Business Units and Business Asset Groups). Entities with no risk are not included in the report. Risks are displayed qualitatively (on a scale of Very Low to Critical). Risks Overview: Presents an overview of the top entities of each selected type. Entities with no risk are not included in the report. Risks are displayed qualitatively (on a scale of Very Low to Critical). Regulation Compliance Risk Details: Presents information about the top Regulations that are at risk of being compromised. It includes detailed explanations of how the risk of each entity is calculated. FISMA/NIST and Risk Assessment reports These reports are used when working with the Exposure feature of Skybox Risk Control. FISMA/NIST reports and Risk Assessment reports present information about systems, threat statements, risk assessment, and actions with milestones. These reports are used to meet FISMA risk reporting requirements. The two types of reports are the same, except that FISMA Risk Management reports use US Government nomenclature, while Risk Assessment reports use standard nomenclature. Note: The text fields in the Properties dialog box for Risk Assessment reports and FISMA Risk Management reports contain placeholder text that you should change before generating these reports for the first time. The information in these fields is used in the introductory section of the report. For additional information about these reports, see FISMA/NIST reports and Risk Assessment reports, in the Skybox View Reference Guide. PCI DSS reports PCI DSS reports are used when working with the Exposure feature of Skybox Risk Control. Skybox Risk Control version

120 Skybox Risk Control User s Guide PCI DSS reports present information about vulnerability occurrences found on system components, including Business Asset Groups, networks, and network devices. The vulnerability occurrences are listed as action items according to their exposure. These reports are usually used to show compliance with PCI DSS requirement 6.1. Note: The Introduction Text field in the Properties dialog box that defines this report is used as the introduction to the report. By default, it contains text that explains how the report demonstrates compliance with PCI DSS requirement 6.1. If the report is used for other purposes (such as to show compliance with a different standard), you should change this text before generating these reports for the first time. For additional information about PCI DSS reports, see PCI DSS reports, in the Skybox View Reference Guide. Predefined PCI DSS report Skybox View includes the following predefined PCI DSS report definitions: PCI DSS Requirement 6.1: Presents vulnerabilities in the organization s network as action items in accordance with PCI DSS requirement 6.1. Tickets reports Tickets reports contain summary and detailed information about tickets. Overview tickets reports are usually used to review and monitor ticket progress, and to see which tasks are assigned to whom. Detailed tickets reports are usually used to implement the changes specified in the tickets. Tickets reports show the status (such as new or in progress), priority, and assigned owner of tickets that meet the report criteria. You can filter these reports according to many different parameters, such as network scope, owner, or due date. For additional information about tickets reports, see the Tickets reports topic in the Skybox View Reference Guide. Predefined tickets reports Skybox View includes the following predefined tickets report definitions: Open Tickets Overview: Presents an overview of open Skybox View tickets, including the priority, status, and owner for each ticket. The tickets are grouped by Priority. Open Tickets Details: Presents detailed information about all open Skybox View tickets. The tickets are grouped by Priority. Overdue Tickets Details: Presents detailed information about all Skybox View tickets that are past their due dates, including the status, priority, and owner for each ticket. The tickets are grouped by owner. Vulnerability Management reports Vulnerability Management reports are high level reports that provide an overview of the vulnerability and risk management process that is similar to what you can see in the Risk Control workspace. These reports contain information about: Discovery: The age and status of vulnerability occurrences and assets (including indication of overdue assets) Analytics: security metrics that need remediation and exposed vulnerability occurrences You can decide to include only discovery or only analytics information. Skybox Risk Control version

121 Chapter 20 Reports For additional information about Vulnerability Management reports, see Vulnerability Management reports, in the Skybox View Reference Guide. Vulnerabilities reports Vulnerabilities reports are technical reports that contain summary and detailed information about vulnerability occurrences found in the model. Usually these reports are used to review the vulnerability occurrences in a specific network segment or location, to filter exposed vulnerability occurrences, to show vulnerability occurrences with a specified severity level, or to show vulnerability occurrences that impose the highest risk on your organization. The reports can also show trends in vulnerability occurrence statistics. In Overview reports, you can see counts of vulnerability occurrences that meet the report criteria. You can group the vulnerability occurrences by operating system, location, Business Units and Business Asset Groups that they affect, and vulnerability definition. In Detailed reports, you can see all information about each vulnerability occurrence that meets the report criteria. In reports that provide Details & Solutions, you can see all information about each vulnerability occurrence and known solutions for mitigating that vulnerability occurrence. For additional information about vulnerabilities reports, see the Vulnerabilities reports topic in the Skybox View Reference Guide. Limiting the scope of vulnerabilities reports It is recommended that you define vulnerabilities reports with limited scopes to avoid excessively long reports. By default, reports involving vulnerability occurrences are limited to 5000 vulnerability occurrences for Overview reports and 1000 vulnerability occurrences for Details (or Details & Solutions) reports for detailed reports, Skybox View does all analyses based on the first 1000 vulnerability occurrences it finds that match the report definition criteria. The detailed information in a detailed report is limited to the first 50 vulnerability occurrences. You can limit the scope of vulnerabilities reports by changing any of the following parameters of the definition on which they are based: The scope of the network to include in these reports The type of operating systems to include in these reports Any of the vulnerability occurrence parameters, including: Imposed risk Status Severity Commonality Vulnerability definition Last scan time To change the scope of a vulnerabilities report definition 1 Right-click the report definition name in the Tree pane and select Properties. 2 Make the desired scope changes. For information about the parameters of vulnerabilities reports, see Vulnerabilities reports, in the Skybox View Reference Guide. Skybox Risk Control version

122 Skybox Risk Control User s Guide 3 Click OK to save the information and close the Properties dialog box. Note: An Admin can change the maximum number of vulnerability occurrences to include in reports. This is not usually recommended. Predefined vulnerabilities report definitions Skybox View includes the following predefined vulnerabilities report definitions: Vulnerabilities Details: Presents detailed information about the vulnerability occurrences in the model. Vulnerabilities Overview: Presents an overview of the vulnerability occurrences in the model. Vulnerabilities Solutions: Presents detailed information about the vulnerability occurrences in the model and suggested solutions for each vulnerability occurrence. Exporting data to CSV files You can export much of the information available in Skybox View in CSV format. The CSV files can then be opened them with applications such as Microsoft Excel for further processing. There are three ways to export Skybox View data to CSV: Via the Tree pane By selecting the table Using tasks To export information about an entity in the Tree pane to a CSV file 1 Select an entity in the Tree pane. 2 Right-click the entity. In most cases, there will either be a Reports shortcut menu with one or more CSV reports available or there will be an Export to CSV option. 3 Select the relevant option. If you want to export a table to CSV that cannot be exported using a shortcut menu option (for example, a table in the Details pane), you can do so using the following instructions. To export a table to a CSV file 1 Display a table (such as a list of vulnerability definitions) in the Table pane or in one of the tabs of the Details pane. For example, to save the list of the vulnerability definitions that contribute to the security metrics score of a particular Business Unit in your organization, select the Business Unit in the tree, and then click the Vulnerability Definitions tab in the workspace. 2 To save specific columns only, make sure that the columns to be saved are displayed in the table and that the other columns are hidden. To display or hide columns, right-click in the header row of the table, select Customize Current View, and check or clear columns as required. 3 Select any row in the table. This focuses the Save operation on the selected table. Skybox Risk Control version

123 4 On the menu bar, select File > Export Table to CSV. 5 In the Save dialog box, navigate to the desired location and click Save. Using tasks to export data to CSV files Chapter 20 Reports Some model data can be exported to CSV using tasks. This is especially useful if you want to export the data on a regular basis. The following CSV tasks are available for Skybox Risk Control: CSV Security Metrics Export CSV Analysis Export Information on these tasks is available in the Skybox View Reference Guide. Exporting vulnerability occurrence data to Qualys format Vulnerability occurrence analyses (lists of vulnerability occurrences) can be exported to XML files in Qualys format for integration with SIEM solutions. To export an analysis to Qualys format Right-click the name of the analysis in the tree and select Export to XML Vulnerability Occurrences. To create a Qualys vulnerability occurrence export task for a specific analysis 1 Create a task of type XML Vulnerability Occurrence (Qualys Format) Export. 2 Use the Analysis Definition field to select the analysis for which you want to create the task. 3 If necessary, change the parameters of the task, including the directory where the files are saved. The default directory is <Skybox_View_Home>/data/csv. Each time the task is run, the table is saved to a file named <analysis_name>_<date>-- <time>.xml in the selected directory. For information about the task parameters, see Qualys format XML vulnerability occurrences export tasks, in the Skybox View Reference Guide. Skybox Risk Control version

124 Chapter 21 Model maintenance Model maintenance includes: Automating tasks for updating the model Confirming that the import and collection tasks ran successfully Validating the model to check for missing or incorrect information Removing entities that are no longer needed General maintenance procedures, such as updating the dictionary and saving the model In this chapter Updating the model General maintenance Updating the model This section explains various activities that you must do to keep the model up-to-date. Automating collection Run collection and import tasks for all devices according to the schedule at which each individual device is updated. For information about scheduling tasks, see Scheduling tasks and task sequences (on page 115). For information about the parameters of each task type, see the section relating to the task in the Tasks section of the Skybox View Reference Guide. Vulnerability occurrence maintenance This information is relevant only when working with Skybox Risk Control. This section explains how to maintain vulnerability occurrences in the model. Vulnerability occurrence life cycle Every vulnerability occurrence has a life-cycle status, from the time it is found by a scanner and merged into the model or defined by a user, until it is finally deleted by the system or by a user. The value of the life-cycle status changes according to user decisions, merging of new scanning results, and ticket processing. Internal life-cycle statuses include: System status: Computed by Skybox View. System status is affected by system algorithms, which also take user decisions into account. User-defined status: Assigned by a user. User status is affected only by direct user decisions about the vulnerability occurrence. The displayed life-cycle status is a value derived from the internal status. Possible values are: Found: The vulnerability occurrence exists in the model Skybox Risk Control version

125 Ignored: The vulnerability occurrence exists in the model but is to be ignored Fixed: The vulnerability occurrence exists in the model, but was fixed Chapter 21 Model maintenance Attack simulation and reports use only vulnerability occurrences whose displayed life-cycle status is Found. Initial vulnerability occurrence life-cycle statuses When data is first imported, all detected vulnerability occurrences are assigned the internal life-cycle status Found by system, which is equivalent to a displayed life-cycle status of Found. During the merging process, another internal status, Suspected False Positive, may be assigned to some vulnerability occurrences. This occurs when there is a mismatch between the asset and the vulnerability occurrence s existence preconditions. For example, if a scanner decides (based on the Windows registry) that a vulnerability occurrence exists for the Microsoft IIS HTTP service, but Skybox View does not find any HTTP ports open on the asset, Skybox View changes the status of that vulnerability occurrence to Suspected False Positive. Suspected False Positive is equivalent to a displayed life-cycle status of Ignored. Vulnerability occurrences marked as Suspected False Positive are not used in attack simulation. For additional information about suspected false positives, see False positive reduction (on page 125). User-defined statuses Users can change the status of any vulnerability occurrence. A user might decide that a vulnerability occurrence should be ignored (not used in attack simulation) for any of the following reasons: It is not very important (no impact). It does not actually exist (false positive). Its risk should be accepted. Vulnerability occurrence aging Scanned vulnerability occurrences go through a process of aging. If the life-cycle status of a scanned vulnerability occurrence has not changed in a set number of days, the vulnerability occurrence receives a system status of Not Found. After another set number of days, it is deleted. If a vulnerability occurrence is rediscovered, it is assigned a system status of Found. For additional information, see Removing outdated entities (on page 126). False positive reduction False positive reduction is relevant only when working with Skybox Risk Control. The False Positive Reduction task checks the model for vulnerability occurrences that may not be exploitable because they do not match their assigned service well enough. The task changes the lifecycle status of these vulnerability occurrences to False Positive. False positive vulnerability occurrences are not used in attack simulation. For example, a vulnerability occurrence is detected on an asset running Microsoft IIS. If the False Positive Reduction task decides (based on the Vulnerability Dictionary) that this vulnerability definition exists only on version 5.1 of IIS HTTP, but the asset on which the vulnerability occurrence is found uses version 5.0, the vulnerability occurrence would be marked as a false positive. The task also checks for patches that fix the detected vulnerability occurrences. If a patch is found on an asset and it is specified in the Vulnerability Dictionary as one that mitigates a vulnerability occurrence found on the asset, the life-cycle status of the vulnerability occurrence is set to Fixed and it is not used in attack simulation. You should run the task at the following times: After adding new data to the model After updating the dictionary Skybox Risk Control version

126 Skybox Risk Control User s Guide For information about the parameters of this task, see False positive reduction tasks, in the Skybox View Reference Guide. Removing outdated entities Network entities (assets, services, vulnerability occurrences, and network interfaces) are added to the model during collection and import. These entities may become outdated or no longer used as the model is updated, but they remain in the model until they are specifically removed. For example, a fixed vulnerability occurrence has its status changed to Fixed, but it is not removed from the model even though it is no longer used for risk analysis. Model Outdated Removal tasks remove from the model network entities that were not changed recently. When the task runs, it compares the last scan time of each entity with the current date and time to establish the entity s age. Entities of a user-defined age (by default, 10 days old) are marked as Down and older entities (by default, 60 days old) are removed from the model. The predefined task of type Model Outdated Removal is named Model Remove Outdated. Run this task on a regular basis to keep the model clean. This task does the following for each network in the model: 1 Decides whether to check the network for outdated entities: If a network was not scanned in the last <n> days (where <n> is the value set in the task), it is not checked by this task for outdated entities. If a network was scanned in the last <n> days, it is checked by this task for outdated entities. Manually created networks (or networks created by ixml import) are never checked for outdated entities. Note: You can configure networks and assets so that they are not checked for outdated entities, see Using the Do Not Outdate option (on page 126). 2 For networks that are checked, calculates the age of each entity in the network, changes the status of entities of a user-defined age to Down (or Not Found, in the case of vulnerability occurrences), and removes older ones from the model. If all network interfaces of an asset are removed (by aging), the asset is removed from the model. Note: This step is sometimes referred to as aging the entities. The ages (in days) are defined in the task. You can check which entities are aged by this task by selecting the Dry Run parameter in the Advanced tab. In a dry run, a list of entities that would be aged by the task is written to the log file but the entities are not aged. You can also run the task but exclude all gateway devices (and their services, vulnerability occurrences, and network interfaces) from the aging process using the Exclude Gateways parameter in the Advanced tab. For information about the parameters of this task, see Outdated entities removal tasks, in the Skybox View Reference Guide. Using the Do Not Outdate option Use the Do Not Outdate option in the Properties dialog box (of the selected network or asset) to mark entities so that they are not checked for outdated entities. When an asset is locked against aging, the asset s network interfaces, services, and vulnerability occurrences are not aged. When a network is locked against aging, the network s assets (together with their network interfaces, services, and vulnerability occurrences) are not aged. Important: Mark entities created manually or by ixml import to protect them from aging, as these entities are usually not scanned or reimported. Skybox Risk Control version

127 General maintenance This section describes general maintenance tasks. Updating your dictionary Chapter 21 Model maintenance Skybox Security releases an updated version of the Skybox View Vulnerability Dictionary on a weekly basis, with additional versions released within one business day of important vulnerability definition releases. It is recommended that you check for dictionary updates on a daily basis. There are two ways to update the dictionary: Use the predefined Dictionary Update Daily task, which takes the most up-to-date dictionary from the Vulnerability Dictionary distribution server. This is the recommended method for updating your dictionary; you can automate it by scheduling the task. Update the dictionary manually from the Skybox Security Customer Support portal ( Note: The dictionary can only be updated by Admins. For instructions about updating the dictionary, see Dictionary updates, in the Skybox View Installation and Administration Guide. Model integrity The following associations between entities in the model cannot be maintained in real time and must be updated on a regular basis: Business Asset Groups and networks Vulnerability definition tickets and networks Use the predefined Model Integrity task to update these associations. When the task runs: For each Business Asset Group that contains networks, it creates an association between the assets currently in the network and the Business Asset Group For each vulnerability definition ticket created for a network scope (rather than for specific vulnerability occurrences of the vulnerability definition), it translates the network scopes for those tickets into assets, so that all vulnerability occurrences of the vulnerability definition that match the ticket can be associated with the ticket. Run this task after you update the model, before running attack simulation or security metrics analysis tasks. Note: If your model does not include any Business Asset Groups that contain networks and you do not have any vulnerability definition tickets for specific network scopes, there is no reason to run this task. Validating the model when working on a continuous basis This information is relevant only when working with the Exposure feature of Skybox Risk Control. You can set up updates to Skybox View to run on a continuous and automatic basis, as discussed in Updating the model (on page 124). However, the update process needs to be monitored on a regular basis to make sure that all tasks succeeded and that all data was successfully imported. Validate the model after each new set of information is added, by making some manual checks as a way of verifying the correctness and completeness of the model. For example: View the model in the Network Map to make sure that there are no unconnected networks or nodes. Skybox Risk Control version

128 Skybox Risk Control User s Guide In the Model Analyses node of the Model tree, check the New Entities analyses if you expect that new entities (such as new assets) were added to the model. Also check the appropriate model validation analyses (on page 70). Check that the item counts for the model (File > Model Properties) are not significantly different from actual numbers of items in your organization s network. For additional information about model validation, see Validating the model (on page 68). Saving the model The model is saved in XML or encrypted XML format. You can load saved versions and use them for analyses in the What If or Forensics model. Note: Only Admins can save and load data. When saving and loading the model, the data is divided into four components. Make sure that you save or load the correct components. For additional information, see Saving and loading the model, in the Skybox View Installation and Administration Guide. Skybox Risk Control version

129 Chapter Part IV: Advanced topics This part includes advanced topics that are relevant to Skybox Risk Control, including advanced modeling scenarios, modeling IPS devices, using the Access Analyzer, adjusting the security metrics parameters, optimizing performance, and tuning issues.

130 Chapter 22 Advanced modeling scenarios This section explains how to model entities that need additional configuration, including: VPN networks L2 networks Overlapping networks (networks in your organization that have identical or overlapping IP addresses and subnets) Virtual routers Virtual firewalls Multi-homed assets Threat Origins from clouds Advanced dependency rules for Business Asset Groups In this chapter Modeling VPNs Modeling L2 networks Overlapping networks Virtual routers Virtual firewalls Clusters Modeling multi-homed assets Merging data Using clouds as Threat Origins Advanced dependency rules Modeling VPNs A VPN is a private network that uses a public network (such as the internet) to connect remote sites or users. There are two types of VPNs: Site to Site: Connects multiple sites over a public network. Remote Access: Connects single users to a LAN from various remote locations Skybox View supports Site to Site VPNs and models them as a direct link between the participating gateways. This link is represented as a special tunnel network. VPN configuration details are represented by VPN units on each gateway. A VPN unit includes protected networks and services, and an interface that connects the gateway to the secure VPN network. Creating VPNs You can create VPNs in Skybox View using collection or import tasks or manually, as described in this section. Skybox Risk Control version

131 Automatic modeling Chapter 22 Advanced modeling scenarios When a VPN is created by collection or import, the configuration of the gateways provides all of the information necessary to create the tunnel network and the VPN units, including the interfaces that connect the VPN units to the tunnel network. Skybox View supports collection and import of VPN information from the following devices: Check Point VPN-1 Cisco IOS firewalls Cisco PIX/ASA/FWSM firewalls Juniper Networks NetScreen firewalls You can model VPN information for other devices manually using the Skybox View Manager or using Skybox View s Integration XML (ixml). For information about ixml, see the Integration part of the Skybox View Developer s Toolkit. In most cases, VPNs are imported automatically as a tunnel of type VpnTunnel with a network interface of type Vpn. For VPNs from specific vendors (such as Cisco), the tunnel can also be of type Tunnel and the network interface of type Tunnel. Note: This issue is vendor-dependent; both configurations model the VPN equally well. Manual modeling When creating a VPN manually, it is recommended that you use the VpnTunnel tunnel type and the Vpn interface type. There are three steps to creating a VPN: 1 Create the (VPN) tunnel network: Each endpoint of the tunnel is the IP address of a connected gateway (see Creating VPN tunnels (on page 131)) 2 Create a VPN unit for each of the two gateways that are connected by the VPN tunnel: Connect the VPN interface of each VPN unit to the (VPN) tunnel network created in the previous step (see Creating VPN units (on page 132)) 3 Create access rules on each gateway, which specify that data should travel over the VPN tunnel: In the VPN pane of each access rule, specify which VPN unit to use (see Creating access rules for the VPN (on page 133)) When any part of the VPN is updated automatically using the appropriate task, the manually created entities and connections are preserved. Creating VPN tunnels When modeling a VPN network manually, you start by creating the VPN tunnel. Afterwards, you connect both gateways to the tunnel via their network interfaces. For information about VPN tunnels, see Creating VPN units (on page 132). To create a VPN tunnel 1 In the Locations & Networks node of the Model tree, right-click the parent node for the tunnel. The parent node can be a specific location in the hierarchy or the Locations & Networks node. 2 Select New > Network. 3 In the New Network dialog box, fill in the fields of the tunnel network: Ignore the default values for the IP Address and Mask fields; these fields are not used for tunnel networks. Skybox Risk Control version

132 Skybox Risk Control User s Guide In the Type field, select Secure VPN or Tunnel, as appropriate for the type of tunnel network that you are modeling. If you are not sure, use Secure VPN. Note: The type of the tunnel and the type of the network interface must match (either Tunnel/Tunnel or Secure VPN/Secure VPN). In the Endpoint 1 and Endpoint 2 fields, type the IP addresses of the connected gateways. For additional information about network parameters, see Networks, in the Skybox View Reference Guide. 4 Click OK. Creating VPN units You create a VPN unit by: Defining which networks and services (in your organization s network) are protected by the VPN Selecting or creating the interface that connects the gateway of the VPN to the tunnel network To create a VPN unit 1 Right-click one of the gateways of the tunnel and select Manage VPNs. 2 In the Manage Host VPNs dialog box, click Add. 3 In the New VPN dialog box, fill in the fields according to the following table. If there is no appropriate network interface for the VPN unit, create one: a) Click New. b) In the New Network Interface dialog box, fill in the fields as appropriate. Type of network interface: For tunnels modeled using the Secure VPN type, select Secure VPN as the Type of the network interface. For tunnels modeled using the Tunnel type, select Tunnel as the Type of the network interface. Note: This issue is vendor-specific. Both configurations model VPN tunnels equally well. Network: In the Network field select the tunnel network to which the VPN unit is connected. If the tunnel network was not created, leave the value of the Network field as None until you create the tunnel network and then change the value of this field to be the newly created tunnel network. For instructions, see Connecting VPN gateways to the tunnel network (on page 133). For information about network interface parameters, see Network interfaces, in the Skybox View Reference Guide. c) Click OK. VPN unit parameters Name Name Original Text My Domain Peer Domain Description The name of the VPN unit The name of the original object from which this unit was generated. The networks protected by this gateway. The networks protected by the endpoint gateway. Skybox Risk Control version

133 Chapter 22 Advanced modeling scenarios Name Services Network Interface Description Only packets with networks that match these domains are allowed to pass thought the VPN tunnel. Note: This field is referred to as the encryption domain in Check Point terminology and the proxy in Cisco terminology. The protected services. The network interface used to connect the VPN unit to the tunnel network. Connecting VPN gateways to the tunnel network If the VPN units were created before the tunnel network, connect each VPN gateway to the tunnel network. To connect a VPN gateway to the tunnel network 1 In the Table pane, select the gateway. 2 In the Details pane, click the Network Interfaces tab. Note: If necessary, click to view the Network Interfaces tab. 3 Right-click the VPN network interface and select Properties. 4 In the Network field of the <Network_interface> Properties dialog box, select the tunnel network from the drop-down list. 5 Click OK. Creating access rules for the VPN After you create the VPN, you create an access rule on each gateway that specifies that data be allowed to pass over the VPN. To create an access rule 1 Right-click the gateway and select Access Rules. 2 In the Access Control List Editor, click New to create an access rule 3 Fill in the fields in the New Access Rule dialog box according to how the data behaves in the actual device (for a description of each field, see Access Rule Properties dialog box, in the Skybox View Reference Guide). a) In the VPN Usage field, select: Specific (to send the data via a specific VPN unit) Any (to send the data over any VPN unit of this gateway) b) If you selected Specific in the VPN Usage field, click the Browse button next to the Specific field and select a VPN unit. 4 Click OK. 5 If necessary, move the new access rule to its correct location in relationship to the other rules using Move Up, Move Down, and Move To. If you created the rule in the wrong rule chain, click Move To Other Chain to move it to the correct chain. 6 Click OK. Skybox Risk Control version

134 Skybox Risk Control User s Guide Modeling L2 networks L3 routers, firewalls, load balancers, and proxies control traffic between different parts of your organization s network and between the organization s network and the outside world. L2 gateways (bridges, switches, and transparent firewalls) are used in an organization network to add additional segmentation or protection. In Skybox View, L2 gateways are only modeled when they affect network accessibility by splitting networks into segments. L2 gateways are modeled in Skybox View in almost the same way as L3 gateways, except that an L2 gateway is marked as Layer 2 and it must have at least one L2 network interface. Access rules for L2 gateways are the same as those for regular (L3) gateways. L2 network interfaces are similar to regular (L3) network interfaces, with the following differences: No IP address is needed: the value is used to represent the IP address. Because an L2 interface has no IP address, it must be connected to a segment, rather than to a network. After the L2 gateway device is created, you divide the network into segments and attach the network interface of the L2 device to the segments. The following figures show the difference between a regular (L3) network and an L2 network. Figure 42: Sample regular (L3) network Skybox Risk Control version

135 Chapter 22 Advanced modeling scenarios Creating L2 devices Figure 43: Sample L2 network You can create L2 devices using collection tasks, import tasks, or manually. You create an L2 device manually in the same way that you create a regular (L3) device, except that you must: Select Layer 2. Create L2 network interfaces for the device. Each L2 network interface is used to connect the device to one of the network segments. The L2 device may have L3 network interfaces. If the device configuration data is collected or imported, Layer 2 is selected automatically. The L2 network interfaces are created but they are not attached to the network; you must attach the interfaces to the network (and segment the network) manually. If the device has L3 network interfaces, these interfaces are automatically attached to the network because they have IP addresses. Segmenting networks In Skybox View, a network segment is a portion of an IP network that is physically separated from other parts of the network by an L2 gateway device. Network segments must be created manually: one for each part of the network that is behind a different network interface of the device. Afterwards, each asset in the network and each network interface of the L2 device must be assigned to the appropriate segment. Note: You can segment the network and assign the L2 network interfaces using Skybox View s Integration XML (ixml). For information about ixml, see the Integration part of the Skybox View Developer s Toolkit. Creating network segments Usually, an L2 device splits a network into two segments. However, in some cases, it may split a network into multiple segments or split multiple networks. Each part of each network separated by the L2 device requires its own manually-created segment. As you create the segments, you assign the appropriate assets in the network to the segment via their network interfaces. Skybox Risk Control version

136 Skybox Risk Control User s Guide To create a network segment 1 In the Model tree, right-click the network to be segmented and select Manage Segments. 2 Click Add. Figure 44: Manage Network Segments dialog box Figure 45: New Segment dialog box Skybox Risk Control version

137 Chapter 22 Advanced modeling scenarios 3 Type a Name for the segment. 4 If necessary, define the IP address ranges for the segment. 5 In the Available field you can see the network interfaces of all assets in this network. For each asset that is in the segment, select the relevant network interface in the Available field and click to move it to the Selected field. 6 Click OK. In the Tree pane, the network contains the segments you created and an Unsegmented Assets node. Figure 46: Tree pane showing a segmented network Assets that are not assigned to a segment in the segmented network are displayed when you select the Unsegmented Assets node. Repeat this process for each segment that you need. Each asset now belongs to a network segment. If the L2 device has a management (L3) network interface, the L3 interface should not belong to either of the segments. The L2 device is listed in every segment, and it is also listed in the Unsegmented Assets node because of the L3 network interface. Note: When a network segment is deleted, all assets (according to their network interfaces) that are part of that segment become unsegmented assets in the network. Configuring the L2 network interfaces After the network is segmented, assign the L2 network interfaces of the L2 device to the appropriate segments. Skybox Risk Control version

138 Skybox Risk Control User s Guide To assign an L2 network interface to a network segment 1 Select the L2 device in the Table pane. 2 In the Network Interfaces tab of the Details pane, select the interface to be connected and open its Properties dialog box. 3 In the Network field, select the network segment to which the interface is attached. 4 Click OK. Figure 47: Properties of an L2 network interface If this L2 device is updated automatically using a task, the connection between the L2 interfaces and their network segments is preserved. Overlapping networks Overlapping networks are networks that have identical or overlapping IP addresses and subnets. These networks are usually located in different parts of your organization, separated by firewalls or routers. These networks are discovered or collected as part of the topology. For Skybox View to distinguish between two overlapping networks, use user-defined locations so that you can assign each such network to a unique location. As new data from these networks is imported into Skybox View, the locations ensure that the networks are kept separate. Importing overlapping networks Before importing network information: Skybox Risk Control version

139 Chapter 22 Advanced modeling scenarios If there are no overlapping networks, you do not need to make any special preparations before importing new information. If you know that overlapping networks exist: 1. Make sure that each overlapping network is in a unique location; if necessary, add these locations to the model before importing the data. For information about defining unique locations in Skybox View, see Defining unique locations for overlapping networks (on page 139). 2. Create a definition file for an Import Advanced task. This file must contain location hints for each overlapping network (see Adding location hints to the definition file (on page 140)). If overlapping networks are identified after the model is built, these networks were merged in the model and may include assets from both overlapping networks. Delete these networks manually from the model, create an input file with location hints, and import the data again. Merging overlapping networks When a network is imported with a location hint, Skybox View attempts to find an identical network under the same location as the specified location hint. The following outcomes are possible: If... Then... An identical network was found under the same location No identical network was found More than one identical network was found Note: This can happen when the location hint is not clear enough. For example, if there are identical networks in the US/New York location and the US/Boston location, and the location hint supplied is [US]. The newly imported network is merged with the existing one in the base model A new network is created in the specified location A warning message is issued and the network is not created When a network is imported without a location hint, the following outcomes are possible: If... Then... If there are no identical networks If there is only one identical network in the model If there are two (or more) identical networks under different locations The new network is created as usual The new network is merged into the base The merger cannot solve the conflict; a warning message is issued and the network is not created When a network cannot be merged for one of the preceding reasons, no new network is created (and no existing network is changed). Assets that are part of overlapping networks are handled in a similar manner. If there are identical assets under different locations, the merger cannot solve the conflict and the asset is not imported. Defining unique locations for overlapping networks To work with overlapping networks in Skybox View, you must define a unique location for each one within the model. Note: Location names must be unique throughout the model even when there are no overlapping networks. Overlapping networks cannot exist in two locations when one location is a direct descendant of the other in the Locations & Networks tree. Skybox Risk Control version

140 Skybox Risk Control User s Guide For example, in the hierarchy in the following figure: Floor 1 and Floor 2 might be used to hold overlapping networks but Floor 1 and Commonwealth may not because Floor 1 is a direct descendant of Commonwealth. Overlapping networks can exist under US and Europe but not under US and Boston. Adding location hints to the definition file To add overlapping networks to the model Figure 48: Overlapping networks - direct descendants 1 Create a definition file for an Import Advanced task. For additional information, see Definition file for advanced import tasks, in the Skybox View Reference Guide. 2 Add location hints to the definition file. Each line used to import an overlapping network must have the following format: <import_format_type> <source_file folder> <[location_hint]> Note: The square brackets ([ and ]) are part of the format of the line; they do not indicate an optional element. For possible values for <import_format_type>, see Data formats for import tasks, in the Skybox View Reference Guide. For example: Skybox Risk Control version

141 Chapter 22 Advanced modeling scenarios NMAP_XML c:\sample\result.xml [London\Bakers] PIX_CONF c:\sample\file.cfg [Paris] You can use both \ and / as delimiters in the location hint. To preserve whitespace in location names, place the location inside double quotation marks. For example: PIX_CONF c:\sample\file.cfg [North America/New York]: The location is read as "NorthAmerica" >> "NewYork" PIX_CONF c:\sample\file.cfg ["North America/New York"]: The location is read as "North America" >> "New York" 3 Using an Import Advanced task, import the overlapping networks into the model. If the location does not exist in the model, it is created during the import. Note: For overlapping networks, the files to be imported using the Import Advanced task must be on the Server computer. Location hints are not identified when the task is run on the Collector computer. Virtual routers Virtual routing is a technology that enables multiple instances of a routing table on the same asset at the same time. Each network interface is associated with one virtual router. When data packets arrive through a specific interface, the asset uses the routing table associated with that interface to route the packets. Packets arriving from different interfaces may take different paths to the same destination. Because each router is independent, the same or overlapping IP addresses can be used without conflicting with each other. In Skybox View each virtual router is modeled as a section in the asset s routing table. Figure 49: Virtual routers Currently, Skybox View supports virtual routers for the following platforms: Juniper Networks NetScreen firewalls (Virtual Routers) Juniper Networks Junos routers and firewalls Cisco IOS firewalls Cisco FW firewalls (in L2 mode) Palo Alto Networks firewalls Foundry Networks firewalls You can model these virtual routers in Skybox View using import or collection tasks. You can model other platforms manually in Skybox View. Skybox Risk Control version

142 Skybox Risk Control User s Guide Virtual firewalls Most vendors offer virtual firewalls, which allow running multiple firewalls on one physical device. Each virtual firewall is associated with (inherits) some network interfaces from the physical device but has a separate ACL and routing table defined for it. In Skybox View, virtual firewalls are modeled as separate firewalls with their respective configurations. All virtual firewalls derived from the same physical device share a common prefix in their names so that they can be easily identified in the model; for example, if the system is named Alex, the virtual firewalls are named Alex:vsys1, Alex:vsys2, and so on. Skybox View also creates an asset group with the name of the system and the virtual firewalls are part of this asset group. Figure 50: Virtual firewalls Currently, Skybox View supports virtual firewalls for the following platforms: Check Point firewalls (VSX) Cisco PIX/ASA/FWSM firewalls (multiple contexts) Fortinet firewalls (VDOM) Juniper Networks NetScreen firewalls (Virtual Systems) Palo Alto Networks firewalls (virtual systems) The feature is supported by import or collection of the firewall configuration data (which adds each virtual firewall as a separate firewall, as the imported configuration files have a separate section for each virtual firewall). You can model other platforms manually in Skybox View by defining a separate firewall for each virtual firewall in the device. Clusters Cisco HSRP clusters Two or more CISCO routers may form a cluster and communicate using HSRP protocol. The redundancy works by declaring a virtual IP address that is always connected to one of the routers in the cluster. Another router in the cluster takes over the virtual IP address if the first router fails. Skybox View models these virtual IP addresses as virtual network interfaces with the naming convention of standby_n (starting at standby_0). In Skybox View, two routers automatically belong to the same cluster if they both have a virtual interface connected to the same network, with the same name and same IP address. These routers are supposed to have the same access rules for each shared virtual interface. Check Point clusters In Skybox View, members of a Check Point cluster are added automatically to an asset group of type Cluster, with the cluster name as the name of the asset group. The shared IP addresses in the cluster are modeled as virtual interfaces in each cluster member. Skybox Risk Control version

143 Other clusters Chapter 22 Advanced modeling scenarios In Skybox View, members of a NetScreen, Junos, or FortiGate cluster are added automatically to an asset group of type Cluster, with the cluster name as the name of the asset group. Modeling multi-homed assets A multi-homed asset is an asset that is connected to more than one network via multiple network interfaces. Unlike gateways, which forward packets between networks, multi-homed assets are not used to forward packets between the networks to which they are connected. Typically, one network is a management network and one is another network, such as production. In Skybox View, a multi-homed asset is a regular non-forwarding asset (generally of type Asset, Workstation, or Server), which has multiple network interfaces. Because the asset is connected to multiple networks, you can see it in each network to which it is connected. In the Network Map, each multi-homed asset appears in all networks to which it is connected. When multi-homed assets are scanned using a network scanner (such as Nmap) or vulnerabilities scanner (such as Nessus or IBM Internet Scanner), they are usually seen from one side only only one network interface is detected and the asset is added to the model as a regular (single-interface) asset. When scanned as part of another network, another side (network interface) is detected; however, no connection between the two IP addresses can be made. Network scans do not usually provide enough information to connect two IP addresses into a multi-homed asset. If multi-homed assets are not correctly modeled, the attack simulation results may not be accurate because Skybox View cannot show attack steps between the networks that are connected to this asset. To correctly model a multi-homed asset, you must inform Skybox View that the asset has several network interfaces. You do this by defining multi-homed assets in ixml and importing them into the model. Skybox View then merges the previously created separate assets into the appropriate multihomed assets. Note: Importing subsequent vulnerabilities scans updates the multi-homed assets without disassembling them. To merge multi-homed assets 1 Create a list of all multi-homed assets in ixml format, where each of the multi-homed assets is defined as a <host> element with an IP address and multiple <interface> elements. Note: You should base the ixml file on an existing list of such assets and their network interfaces. For additional information, see <host> element, in the Skybox View Developer s Guide. For help in creating this list, contact Skybox Security s Professional Services team. 2 Import this list to Skybox View using any import task. The merger locates every piece of each asset and connects them together into multi-homed assets. If a multi-homed asset is modeled as described, the procedure does not need to be repeated. Subsequent data imports (such as an Nmap scan of one interface) are merged correctly with the multihomed asset. If there are problems with subsequent data imports, see Troubleshooting multi-homed assets (on page 143). Troubleshooting multi-homed assets As stated, multi-homed asset definitions are not changed by subsequent imports. However, there may be cases of data conflict, such as when: Several assets share the same IP address Skybox Risk Control version

144 Skybox Risk Control User s Guide A newly imported asset does not exactly match an existing asset This section explains how Skybox View processes these situations. Assets with more than one candidate in the model When you import a multi-homed asset and there are two or more similar assets in the model, Skybox View tries to find the best match for the incoming asset by finding the (existing) asset that has the greatest number of matching interfaces (same IP address). For example, there are two assets in the model: Asset X with IP 1 and IP 2 Asset Y with IP 1 and IP 3 A new asset named Asset Z is imported, with IP 1 and IP 3. Skybox View tries to find the asset with the greatest number of matching IP addresses and Asset Z is merged with Asset Y. A new asset named Asset A is imported, with IP 1 and IP 4. In this case, there is not enough information to decide between Asset X and Asset Y for the merge; Asset A is added to the model as a new asset but is not merged with either existing asset. Assets with only one candidate asset in the model If there is only one candidate asset in the model with an interface that has the same IP address as the incoming asset, Skybox View uses a specific formula to determine whether the incoming asset matches the existing asset (and should be merged with it) or whether to add the incoming asset to the model as a new asset. Skybox View does the following to determine whether the assets match: 1 Count the number of matching interfaces (of the asset in the model and the incoming asset) 2 Divide by the number of relevant interfaces in the asset that is in the model. If this number is larger than the heuristics threshold, the assets are merged. If this number is smaller than the heuristics threshold, the assets are not merged. The value of the heuristics threshold is set by the com.skybox.view.logic.discovery.modelsmerger.multi_home_heuristics_threshol d parameter. Changes to this parameter must be made in <Skybox_View_Home>\server\conf\sb_common.properties on the Server machine and in <Skybox_View_Home>\collector\conf\sb_common.properties on the Collector machine. The default value of the heuristics threshold is 0.5. If an asset that should merge does not merge, decrease the value of the heuristics threshold. If an asset merges when it should not, increase the value of the heuristics threshold. Merging data All data that is imported, collected, discovered, or scanned into the model goes through a process named merging, which refines the data and merges the information into the current model. Only data that is added to the model manually does not go through this process. When new data is retrieved for Skybox View, it is collected into an update model. This data is normalized into the format in which it is stored in Skybox View (see Normalizing the network information (on page 145)) and merged into the base model (usually the Live model) on a per-entity basis using the following process: Skybox Risk Control version

145 Chapter 22 Advanced modeling scenarios 1 Identify the entity in the base model (see Identifying entities in the base model (on page 146)). If the entity is new (does not exist in the base model), the second step is skipped and the entity is added to the base model. 2 Merge the entity s data from the update model to the base model (see Merging entities (on page 146)). You should understand when data will be merged and what criteria are used for merging each type of entity, so that you know which new data will be accepted into the model and which will be discarded. Usually, merging is a transparent process; sometimes you must prepare the model to allow merging to proceed correctly. Normalizing the network information Skybox View performs the following actions to normalize the update model: Network status: If the network status is UNKNOWN, it is set to UP. If the interface type is unknown and it is a Loopback interface, its type is set to LOOPBACK; otherwise, the interface type is set to ETHERNET. Discovery method for assets, and for access and routing rules: If the discovery method is null, it is set to UNKNOWN. Last scan time for assets and services: If the last scan time of an asset or a service is null, it is set to the current time. Network interfaces for devices and assets: Every interface is attached to the correct network Empty ( ) interfaces are removed Access rules that are attached only to empty interfaces are removed Assets that do not have at least one interface that can be primary are removed Note: When an entity is removed from the update model, it is not used in the merger at all, because it does not meeting the qualifying criteria. If a network interface has no name, Skybox View generates a name of the form nif<n>, for example, nif7 Routing rule gateways: If a routing rule has a zero gateway and other (non-zero) gateways, the zero gateway is removed If a routing rule does not have any gateways, a zero gateway is added Assets: If an asset has no name, Skybox View generates a name of the form host<n>, for example, host13 ) If an asset has duplicate services, one of them is removed After the data in the update model is normalized, the following resolutions are performed: Patch identification: Each patch is assigned to a service product (using product banner matching) Asset type deduction: The type of each asset is deduced from the services running on the asset OS fingerprints translation: The operating system banner is matched to the appropriate service definition Product banner translation: Service banners are analyzed to find a match in the Skybox View Vulnerability Dictionary Skybox Risk Control version

146 Skybox Risk Control User s Guide Vulnerability catalog ID resolution: Vulnerability catalog IDs are resolved using the Vulnerability Dictionary Vulnerability occurrence matching: Some vulnerability occurrences are discovered indirectly by scanners and then assigned incorrectly. For example, a scanner grabs information about an asset s services via SNMP and assigns the vulnerability occurrences found to SNMP; these vulnerability occurrences must be matched to the correct service. Some scanners do not report which service is vulnerable, rather they provide two separate lists all vulnerability occurrences found on the asset and all services found on the asset. In this case, the link between services and vulnerability occurrences must be created. Identifying entities in the base model Each type of entity has different criteria for identification. For example: Most types of networks are identified by their IP address and mask. Assets are identified by their network interfaces. When importing a new asset, the merger ascertains whether the asset exists in the model by looking for an asset with at least one network interface with the same IP address that is not of type Virtual, Loopback, Tunnel, or LoadBalancer. Services on the same asset are identified by their ports. If it is established that an entity in the update model is new (does not exist in the base model), it is added directly to the base model, without going through the final step (entity merge). Merging entities If an entity in the update model exists in the base model, there are two ways to merge the data: The information in the two models is combined The information in the base model is replaced by the information in the update model Although the methods for merging each entity type are different, the main criteria for the merge are: Reliability of source For example, imported gateway configurations are considered the most reliable source. Data retrieved from SNMP is considered more reliable than data retrieved by a network scan because it usually contains more detailed information about service and network configuration of the asset. If the source of the base model s data is more reliable (more accurate and more complete) than the source of the update data, either no merge is performed or only new information from the update model is used. Note: The parameters in the discovery properties (Server & Collector) section of <Skybox_View_Home>\<component>\conf\sb_common.properties (where <component> can be server or collector) define the order of source reliability for different entities. Time Newer data is preferred to older data. Time is measured according to the Last Scan Time timestamp. Completeness Some data is better than none. Skybox Risk Control version

147 Chapter 22 Advanced modeling scenarios If the data in the update model for a specific entity is older, less reliable, or less complete than the data in the base model, the data from the update model is discarded and the entity in the base model is not changed. Merging assets The following types of network interfaces are used to identify assets: NAT Ethernet WLAN Tokenring PPP Slip Other Serial Tunnel Network interfaces of types Virtual, Loopback, and LoadBalancer are not used for identification. Note: When importing asset information, an asset that has different (dynamic) IP addresses in the two models is not merged. To ensure that all asset data is merged, use the Merge assets by Wins name field in the import and collection tasks. When a task is run with this flag, the merger looks first for identical WINS names for merged assets and, if not found, falls back to comparing IP addresses. When Skybox View decides that an asset in the base model and an asset in the update model are actually the same asset, all elements of the asset are merged, including: Network interfaces Routing rules Access rules Services Vulnerability occurrences Each element is merged separately, on the basis of reliability, time, and completeness (see Merging entities (on page 146)). Network interfaces In general, interfaces are merged according to reliability and time. If the discovery method in the update model uses CONFIG or SNMP, which are considered the most reliable sources, the interfaces in the update model overwrite those in the base model. Otherwise, the new interfaces are merged with those in the base model. Note: When working with routers, the default behavior of the merge is to disconnect manually connected network interfaces. To prevent this, ensure that the Network field of the network interface is Locked ( Routing rules ) before the routers are updated. When merging routing rules, only the whole routing table is considered; individual routing rules are not merged separately. Routing tables are merged according to reliability and time. Skybox Risk Control version

148 Skybox Risk Control User s Guide If the routing table from the update model is more reliable or newer, it overwrites the routing table in the base model. If the base asset does not have a routing table, the routing table from the asset in the update model is used. Access rules When merging access rules, only ACLs are considered; individual access rules are not merged separately. ACLs are merged according to reliability and time. If the ACL in the update model asset is more reliable or newer, its access rules overwrite the ones in the base model. If the base asset does not have any access rules, the access rules from the asset in the update model are used. Services When merging the services of two assets, the merger adds new services that do not appear in the base asset and merges the data of services that do exist in the base model. When merging services, the vulnerability occurrences attached to the service are also merged. Vulnerability occurrences New vulnerability occurrences on the updated asset s services are added to the base model. If a vulnerability occurrence already exists in the base model, the vulnerability occurrence data is merged. Merging networks Regular and link networks are identified by their IP address and mask. Some types of networks have slightly different rules for identification because a single IP address and mask cannot be used to identify them. Tunnel networks and Secure VPN networks are identified by the IP addresses of their endpoints. For information about tunnel parameters, see the Networks topic in the Skybox View Reference Guide. Connecting Clouds are identified by their name. Perimeter Clouds are identified by their IP address and network mask. If necessary, the cloud name is also used. The following rules are applied when merging networks: New networks are added directly to the base model. If the network in the base model contains the updated network, the network is not added. Network segments are merged in the context of their networks. Network segments are identified by their network and their name. Note: When merging networks, the last scan time and the discovery method are ignored. Skybox View handles networks that have identical or overlapping addresses or masks using a different method, so that the networks are not accidentally merged. For information about how overlapping networks are merged, see Merging overlapping networks (on page 139). Merging link networks when each part is in a separate location A link network is a network whose only assets are gateways (routers and firewalls) that connect networks. If a link network consists of gateways that are in two different locations and were imported with different location hints, the merger assigns each part of the link network to its own location as a separate (but incomplete) network and does not know how to connect them. In effect, overlapping networks are created instead of one single network. Manual action on your part is required when merging link networks. Skybox Risk Control version

149 To merge a link network 1 Manually delete all duplicate overlapping link networks. 2 Move the remaining network to the parent location. If the network has no parent location, move it to the root location. 3 Run the import again. Using clouds as Threat Origins Chapter 22 Advanced modeling scenarios Possible access from Threat Origins to Business Asset Groups and assets is translated by the attack simulator into attacks and risk. Under normal circumstances, when clouds (such as the internet or a partner) are used as Threat Origins, the risk is not affected by the number of source IP addresses in the cloud that can initiate the attack; an attack that is possible from any address in the internet and an attack that is possible from only one specific address in the internet are assigned the same risk. However, this may not be the desired effect. You can differentiate between these two types of attacks in two different ways: You can configure Threat Origins that are located in clouds so that during attack simulation, Skybox View assigns a lower risk for a small number of source IP addresses and a higher risk for a large number of source addresses. You can create two Threat Origins for a single cloud, one that develops attacks that are possible from wide ranges of source IP addresses of the cloud and the other that develops attacks that are possible only from specific addresses (that is, from small address ranges). The first Threat Origin (wide address ranges) is typically assigned a relatively high likelihood; the second Threat Origin (specific addresses only) is typically assigned a lower likelihood. By defining two Threat Origins you can view separately attacks that are possible from a wide range of source addresses and the attacks that are possible only from several specific addresses (such as IP addresses allowed for secure protocols over the internet). If you then assign each Threat Origin to a different Threat Origin Category, the exposure and risk for each can be completely separate. To define how to use cloud addresses to use for a specific Threat Origin 1 In the Table pane, right-click the Threat Origin and select Properties. 2 In the Advanced tab, select the type of cloud IP address ranges to be used in an attack from this Threat Origin: All addresses (default), Wide address ranges, or Specific addresses only. 3 If you selected All addresses and you want attacks from specific IP addresses to be given a lower risk than those from wide address ranges, select Lower likelihood for attacks from specific addresses. Advanced dependency rules This section explains how advanced dependency rules work in Skybox View. Implicit dependencies By default, implicit dependency specifies that both: A security loss of any type (confidentiality, integrity, or availability) on a Business Asset Group member implies the same type of security loss on the Business Asset Group An integrity loss on a Business Asset Group member implies an availability and confidentiality security loss on the Business Asset Group An implicit dependency is created automatically when you assign assets to a Business Asset Group. However, you can change the dependency between the Business Asset Group and its assets to: Skybox Risk Control version

150 Skybox Risk Control User s Guide Simple: A security loss of any type (confidentiality, integrity, or availability) on a member implies the same type of security loss on the Business Asset Group. None: This method of describing the dependency is not sufficient and you prefer to specify (using explicit dependency rules) how a security loss on each of the Business Asset Group members affects the Business Asset Group. To change the implicit dependency of a Business Asset Group 1 In the Business Units & Asset Groups branch of the Model tree, navigate to the desired Business Asset Group. 2 Right-click the Business Asset Group and select Properties. 3 In the <Business_Asset_Group_name> Properties dialog box, change the value of the Member Dependency field as appropriate. If you change the value to None, define explicit dependency rules for each Business Asset Group (see page 84). 4 Click OK. Explicit dependency rules You can use explicit dependency rules for several purposes: To define a dependency of Business Asset Groups on infrastructure elements (such as a DNS server or Authentication server: LDAP, RADIUS, TACACS, or router/firewall). For example, when an e-business application depends on the DNS server. To define dependencies between Business Asset Groups. For example, when the availability of one Business Asset Group depends on the availability of another Business Asset Group To define dependencies between assets (or between assets and Business Asset Groups). For example, to express that the confidentiality loss of a sensitive server potentially compromises a different server in your organization. To define explicit dependency rules for each asset, if one implicit dependency rule does not match all assets on a Business Asset Group. You can use simple dependency rules to create complex dependency situations, for example: Z depends on Y. Y depends on W and X (at least one dependency). Based on these two rules, a security loss on X indirectly causes a security loss on Z. To create explicit dependency rules In the Model tree, right-click the Dependency Rules node and select New Dependency Rule. For a list of parameters of dependency rules, see Dependency rules, in the Skybox View Reference Guide. Skybox Risk Control version

151 Chapter 23 Additional information about exposure This chapter presents advanced information about exposure in Skybox View. In this chapter About attack simulation About risk Skybox View analyses Viewing risk PCI DSS support in Skybox Risk Control About attack simulation This section presents advanced information about attack simulation. Data used for attack simulation Data for simulation is collected from the model and includes: Network and routing information Network interfaces Routing rules NAT rules Access rules Business information Business Impact rules relating to confidentiality, integrity, and availability Regulations assigned to each Business Asset Group Vulnerability occurrences Note: Only vulnerability occurrences with status Found are used in attack simulation. Vulnerability occurrences with status Ignored or Fixed are not used. Output of attack simulation The output of attack simulation is: An attack graph, which captures all possible attacks scenarios on your network to the specified Business Asset Groups. You can use the Attack Explorer to view maps for selected entities in the model, based on the attack graph. Risk levels for Business Asset Groups according to the likelihood of their being attacked and the impact of these attacks. Imposed risk levels for Threat Origins and vulnerability occurrences. Exposure levels for vulnerability occurrences, including: Direct: Vulnerability occurrences that a Threat Origin can exploit in one step. Skybox Risk Control version

152 Skybox Risk Control User s Guide Indirect: Vulnerability occurrences that a Threat Origin can exploit, but only in more than one step. Protected: Vulnerability occurrences that cannot be accessed by an attacker because they are protected by an IPS device. Potential: Vulnerability occurrences that have an accessible service (such as HTTP), but may not be accessible because of other exploit conditions that cannot be guaranteed (for example, authentication may be required). Inaccessible: Vulnerability occurrences that cannot be accessed by an attacker (for example, the vulnerable service is disabled or the vulnerability occurrence is blocked by a firewall). Excluded: Vulnerability occurrences excluded from attack simulation. (Attack simulation excludes vulnerability occurrences with the following statuses: False Positive, Fixed, or Ignored.) Unknown: Vulnerability occurrences with unknown exposure. The exploit conditions of these vulnerability occurrences are irrelevant for attack simulation (for example, a browser weakness that may cause damage to a workstation if its user surfs to a hostile website). A list of attacks. An attack is a high-level representation of attack scenarios. Each attack has one Threat Origin and one destination, the starting and ending points of the attack scenarios it represents. The destination may be an asset or a Business Asset Group. The Attack Explorer is based on the attack graph and allows you to understand the steps taken in specific attacks. Skybox View s summary graphs and tables, analyses, and reports about exposure are also based on the output of attack simulation. Attack simulation from clouds In many cases, clouds include a small number of specific IP addresses that are allowed through firewalls for management purposes or for supplying certain services for specific users, such as IP addresses that are allowed for secure protocols over the internet. When such a cloud is used as a Threat Origin, the possible access from these IP addresses is translated by the attack simulator into attacks and risk. When using the default settings for Threat Origins, the risk is not affected by the number of source IP addresses that can initiate the attack; an attack that is possible from any IP address and an attack that is possible from only one specific address are assigned the same risk. You can configure Threat Origins located in clouds so that during attack simulation, Skybox View assigns a lower risk for a small number of source IP addresses and a higher risk for a large number of source addresses. For additional information, see Using clouds as Threat Origins (on page 149). About risk This section presents advanced information about risk on various entities including what information is used to calculate the risk and various options for displaying the risk values. Risk formula Note: This section describes the risk formula for a Business Asset Group risk for most other entities is based on the risk to the Business Asset Groups. The risk for a Business Asset Group depends on two factors: the likelihood of successfully attacking the Business Asset Group and the potential damage that caused by the security loss. Formally, Risk = Likelihood * Impact Skybox Risk Control version

153 Impact Chapter 23 Additional information about exposure The impact of a security loss is part of the user input to the security model. The impact can be a Business Impact or a Regulation (a compromise to a security-related regulation) and includes damage rules for each type of security loss (confidentiality, integrity, and availability), associating with the loss type an estimation of the potential damage. The damage can be specified as an explicit monetary value or as a level on a five-level scale (very low, low, medium, high, critical), where each level represents a monetary value indicating the magnitude of the damage (for example, low could be $10K, medium could be $100K, and so on). Likelihood of attack The likelihood of an attack causing damage to a Business Asset Group is calculated separately for each of the impact rules of the Business Asset Group. To compute the likelihood of causing the damage specified by an impact rule on a Business Asset Group, the system examines every attack path from the Threat Origins that can cause the security loss specified by the impact rule (for example, an availability loss of the Business Asset Group). Each of these attack paths starts at a Threat Origin and includes a sequence of attack steps that an attacker can perform to cause the security loss. An attack step is either the exploitation of a vulnerability occurrence or the legitimate usage of a service (such as telnet or FTP). The computation of the attack path likelihood takes into account: The likelihood that an attack will be initiated from the Threat Origin (as estimated by the user who defined the Threat Origin) The number of attack steps in the attack path The likelihood of success of each of the attack steps The likelihood of successfully exploiting a vulnerability occurrence is calculated using the following factors: The difficulty of exploiting the vulnerability occurrence. Greater difficulty leads to a lower success probability. The exploitation difficulty is a parameter of each vulnerability definition in the Skybox View Vulnerability Dictionary. The skill of the attacker (as estimated by the definer of the Threat Origin). A higher skill level has a higher probability of success. The commonness of the vulnerability occurrence. A vulnerability definition that is known to be popular among hackers has a higher success probability. Computing the likelihood of an attack path involves multiplying the Threat Origin likelihood by the probabilities of the attack steps along the attack path. When a damage specified by a Business Impact or Regulation can be caused by more than one attack path, the likelihood of causing the damage is set as the likelihood of the most probable attack path (the path with the highest likelihood). How risk is defined for each type of entity Business Asset Groups A Business Asset Group may be at risk because of attack paths leading to exploitable vulnerability occurrences that reside on the Business Asset Group s assets or on assets on which the Business Asset Group depends. The risk for a Business Asset Group is the maximum of all risks of attack on that Business Asset Group. In the risk formula (Risk = Impact * Likelihood), the impact for a Business Asset Group is derived from the Business Impacts and Regulations configured for that Business Asset Group. The likelihood to attack a Business Asset Group is considered very low if no possible attacks are found. If attacks are possible, the likelihood depends on the difficulty of the attacks (number of required attacks steps, existence of automatic tools for exploiting the vulnerability occurrences, and so on). Skybox Risk Control version

154 Skybox Risk Control User s Guide Business Units Risk for a Business Unit is the aggregated risk (sum) of attack for all Business Asset Groups of the Business Unit. Business Impacts and regulations Risk for a Business Impact or Regulation is the risk that the Business Impact or Regulation is under based on the risk of its Business Asset Groups. The risk is calculated by aggregating the risks of the Business Asset Groups affected by this Impact. Threat Origins Risk for a Threat Origin is the risk that the Threat Origin poses to your organization due to its ability to exploit vulnerability occurrences and attack Business Asset Groups. The risk (imposed risk) is the sum of all risks imposed by the selected Threat Origin on all Business Asset Groups configured in the system. Note: A Threat Origin can impose a risk on a Business Asset Group only if an attack path leads from the Threat Origin to the Business Asset Group. Attacks Risk for an attack is the risk that a specific Threat Origin poses to a specific Business Asset Group. Each attack consists of a source Threat Origin and a destination Business Asset Group or asset. Factors that make up the attack risk include the different ways to attack the destination from the source (the attack scenarios), the likelihood that these attack scenarios may be performed, and the different damages that the attack scenarios can cause. Vulnerability occurrences Risk for a vulnerability occurrence (or a vulnerability definition) is the risk that the vulnerability occurrence poses to your organization because it can be potentially exploited to damage Business Asset Groups. Each vulnerability occurrence is assigned an imposed risk derived from two factors: Risk imposed because the vulnerability occurrence participates in attacks Risk imposed because the vulnerability occurrences exist on assets, even though there are no attack paths that allow exploitation The combination of these two factors is the total risk from the vulnerability occurrence. Note: Even vulnerability occurrences that not are located on an asset of a Business Asset Group pose a risk, as long as they can be used as part of an attack on the Business Asset Group. The imposed risk creates a differentiation between vulnerability occurrences: Exposed vulnerability occurrences (directly or indirectly) that do not lead to security loss of Business Asset Groups are usually assigned a very low risk. Vulnerability occurrences that are exposed and can lead to damage are assigned a high risk based on the involved damage values and the likelihood of achieving these damages. For example, one vulnerability occurrence is directly exposed to a specific Threat Origin, but its imposed risk is very limited because it does not lead to a subsequent attack on a major IT asset; another vulnerability occurrence has a high imposed risk because it can be used to attack the Back End Payment System. Both vulnerability occurrences have high severity (the attacker can use them to achieve control), but the consequences of achieving control are different in the two cases. Skybox Risk Control version

155 Display of risk values Chapter 23 Additional information about exposure Risk values in Skybox View are usually displayed as levels (undefined, very low, low, medium, high, or critical), using a color scale. You can also display the risk values: As monetary values Figure 51: Risk - displayed as levels Note: Monetary risk values are approximate values that allow comparison between risks of different entities at a higher resolution than is possible with levels or scores. They are not meant to represent actual monetary values. Using a score of Figure 52: Risk - displayed as scores Note: Admins can tune the mapping between levels or scores and monetary values to match your organization s range of damage values. Skybox Risk Control version

156 Skybox Risk Control User s Guide You change the display of risk values in the Options dialog box (select Tools > Options > Manager Options > Risks Configuration, and change the value of the Risk Value Style parameter). Skybox View analyses A Skybox View analysis is a query about a type of entity in your network, such as assets, Business Asset Groups, Threat Origins, networks, or vulnerability occurrences. Each time an analysis is selected, Skybox View checks all entities of the selected type to see whether they meet the specified criteria. Entities that meet all the criteria specified in the analysis are listed in the Table pane. Skybox View includes various predefined analyses for common issues; you can also create custom analyses to suit the needs of your organization. The Exposure workspace includes an Analyses node, which you can use to view information about the following types of entities: attacks, Business Asset Groups, Business Units, assets, locations, networks, Business Impacts, regulations, Threat Origins, vulnerability occurrences, vulnerability definitions, and worms. The analyses in this workspace are mostly intended to show risk. Figure 53: Risk analyses There are also analyses in other workspaces. For example, the Model workspace includes analyses related to the model, such as one that lists all assets in the model that are mail servers, and analyses that provide validation information about entities in the model, such as firewalls with no access rules. For additional information about analyses, see Analyses, in the Skybox View Reference Guide. Skybox Risk Control version

157 Risk analyses Chapter 23 Additional information about exposure Skybox View includes predefined risk analyses for all entities that are affected by risk, including attacks, Business Asset Groups, Business Units, vulnerability occurrences, Threat Origins, and Regulations and Business Impacts. The predefined risk analyses show risk for all entities of their type, but you can modify them as necessary. You can also create analyses that, for example, focus on specific network scopes, only show risk above a specific level, and so on. Each risk analysis shows information about the entities that match the analysis criteria and their associated risk. The information varies according to the type of entity. For example, Business Impacts by Risk shows the name and loss types defined for each Business Impact, while Threat Origins by Risk shows attacker information including location, likelihood to attack, skill, and initial privilege on the attacking computer. Predefined risk analyses Skybox View includes the following predefined risk analyses: Business Asset Groups by Risk: This analysis displays your organization s Business Asset Groups with associated risk information. The risk for a Business Asset Group is the maximum of all risks of attack on the Business Asset Group. Vulnerability Occurrences High Risk: This analysis displays vulnerability occurrences with High and Critical imposed risk. Information about each vulnerability occurrence includes the severity and exposure, CVE ID, status, title, asset, service, age, whether a ticket was opened on the vulnerability occurrence, and the imposed risk. There are other analyses that display information about vulnerability occurrences, such as the Vulnerabilities > By Exposure analyses. Vulnerability Definitions High Risk: This analysis displays vulnerability definitions with High and Critical imposed risk. A vulnerability definition has high risk if any of its vulnerability occurrences in the model have high risk. Information about each vulnerability definition includes a list of all its vulnerability occurrences in the model, with their risks. Threat Origins by Risk: This analysis displays Threat Origins with information about their imposed risk. The risk for a Threat Origin is the sum of all risks imposed by that Threat Origin on all Business Asset Groups configured in the system. Attacks High Risk: An attack consists of a Threat Origin and a destination (Business Asset Group or asset). This analysis displays the Threat Origin, destination, risk, and step count the number of steps it would take for the Threat Origin to attack the destination. The risk for an attack is the risk that the source Threat Origin poses to the destination Business Asset Group. No risk is displayed for attacks on assets. Business Units by Risk: This analysis displays Business Units with associated risk information. The risk for a Business Unit is the aggregated risk for all Business Asset Groups of the Business Unit. Business Impacts by Risk and Regulations by Risk: These analyses display the risk for Business Impacts and Regulations and the type of loss involved (confidentiality, integrity, and availability). The risk for a Business Impact or Regulation is the aggregation of the risks associated with that Business Impact or Regulation on the individual Business Asset Groups. Skybox Risk Control version

158 Skybox Risk Control User s Guide Creating an analysis You create analyses to view sets of related data that are not otherwise available. For example, you might want to see all high risk vulnerability occurrences on assets that belong to a specific network, all assets or locations that have vulnerability occurrences, or all Business Asset Groups that have at least a specific number of assets and a specific risk level. To create an analysis in the Risk Control workspace 1 In the tree, right-click Analytics Center > Analyses > Private Analyses and then select New > Analysis. Figure 54: New Analysis dialog box 2 Type a Name for the analysis. 3 Select the analysis type. 4 Fill in the fields according to the appropriate table (in the Skybox View Reference Guide): Assets analyses Attacks analyses Business Asset Groups analyses Business Units analyses Locations analyses Networks analyses Regulation Compliance analyses Threat Origins analyses Vulnerability occurrences analyses Vulnerability definitions analyses Worms analyses 5 Click OK. The analysis is created. Skybox Risk Control version

159 Chapter 23 Additional information about exposure Sometimes, when you create a new analysis, the table in which it is displayed is missing information that you would like to see. You can adjust the table to show additional columns. To adjust the table to show additional columns 1 With the newly created analysis open, right-click in the header row of the Table pane and select Customize Current View. 2 In the Customize Current View dialog box, select the information that you want to see and click OK. A new column with this information is added to the right-hand side of the table. 3 If necessary, drag the column header to a more convenient location in the table. Skybox Risk Control version

160 Chapter 24 Viewing risk You can view risk information in several ways, including: On the Exposure Summary page: In the Direct Vulnerability Occurrences by Risk graph In the Threat Origins by Risk table From any table in the Exposure area (such as vulnerability occurrences, Threat Origins, attacks, risks), where risk is always one of the columns in the table Risk profiles (on page 160): The major components that contribute to the risk for a selected entity Risk factors (on page 161): How the combination of a source (Threat Origin), a destination (Business Asset Group or asset), and a Business Impact or Regulation (explaining the potential loss from the risk factor) can affect the selected entity. The Attack Explorer (on page 90): Information about the assets, services, and vulnerability occurrences in the system, in the context of specific attacks Risks reports (on page 119): Information about high-risk entities of a specific type, such as vulnerability occurrences or Business Asset Groups Risk analyses (on page 157): Risk for all entities that meet the analysis criteria for example, one analysis shows risk for all critical vulnerability occurrences and another shows risk for all critical Business Units In this chapter Risk profiles Risk factors Risk profiles The risk profile for an entity shows the major components that contribute to the risk for that entity. You can view risk profiles for: Business Units and Business Asset Groups Business Impacts and Regulations Vulnerability occurrences To view the risk profile for an entity Select the entity in the Table pane and click the Risk Profile tab in the Details pane. Risk for Business Units and Business Asset Groups is caused by attacks from Threat Origins. The risk profile of a Business Unit or a Business Asset Group shows the risk from all sources (that is, the total risk), followed by the specific risk from each Threat Origin Category. Risk for Business Impacts and Regulations is caused by Business Asset Groups that are affected by the Business Impact or Regulation. The risk profile of a Business Impact or Regulation shows the risk from all sources, followed by the specific risk from each Business Asset Group. Skybox Risk Control version

161 The risk profile of a vulnerability occurrence shows: Chapter 24 Viewing risk The Business Asset Groups (and Business Units) that the vulnerability occurrence could be used to attack. The risk from each Threat Origin Category that could be used to exploit the vulnerability occurrence. Risk factors A risk factor is a single risk either to an entity or imposed by an entity. In general, risk for entities is calculated by computing the maximum risk from all risk factors for the entity. Each risk factor involves a source (Threat Origin), a destination (Business Asset Group or asset), and a Business Impact or Regulation that explains the potential loss from the risk factor. Risk factors are an advanced parameter of the following entities: Business Units Business Asset Groups Threat Origins Attacks To view the risk factors for an entity Select the entity in the Table pane and click the Risk Factors tab in the Details pane. Note: If necessary, click to view the Risk Factors tab. Figure 55: Risk Factors In this example, the Source of the first risk factor is Internet Hacker, the Target is Back End Finance Application Servers, the Business Impact Name is Financial Information Confidentiality, and it is high risk. The source and destination of some other risk factors are the same as the first, but, because the Business Impact is different for each of these, the risk is different. PCI DSS support in Skybox Risk Control Skybox Risk Control supports PCI DSS version 1.2, requirement 6.1: Ensure that all system components and software have the latest vendor-supplied security patches installed. Install critical security patches within one month of release. Note: An organization may consider applying a risk-based approach to prioritize their patch installations. Skybox View s PCI DSS Requirement 6.1 report shows how the network for which the report is issued meets this requirement using compensating controls. Skybox Risk Control version

162 Skybox Risk Control User s Guide The report includes the following sections: Introduction: Describes the requirement, including the compensating controls form. This text follows PCI DSS version 1.2, Appendix C: Compensating Controls Worksheet. System Components: Lists the scope of the report (which Business Asset Groups, networks, and network devices are included). Vulnerabilities: Lists the vulnerability occurrences that must be remediated for the network to become compliant with this standard. Host Lists: Lists the individual assets in the scope of the report and states whether they are compliant (that is, have no direct, indirect, or unknown vulnerability occurrences) with this standard. For additional information about this report, see PCI DSS reports (on page 119). For information about defining these reports, see the PCI DSS reports topic in the Skybox View Reference Guide. Skybox Risk Control version

163 Chapter 25 Access Analyzer The Access Analyzer analyzes access in the network, taking into account access rules, routing rules, assets, and services. You can use the Access Analyzer for many purposes, including verifying network connectivity and network security in existing scenarios (Live) and test scenarios (What If), and for troubleshooting the network. This section explains how to use the Access Analyzer. In this chapter Creating new queries Access Analyzer output Creating new queries The Access Analyzer works by answering queries about access within your organization s network. The Access Query pane is used to create queries. It contains input fields (including source, destination, and specific access parameters such as IP address spoofing) that tell the Access Analyzer what access you want it to verify and what additional factors to consider in the analysis. To define a query 1 Open the Access Analyzer: click on the toolbar. Figure 56: Access Analyzer 2 Define the source and the destination (see page 164). Note: The Source or the Destination must be given a value (that is, at least one of them must not be Any). For information about these and other parameters, see Access Analyzer query fields, in the Skybox View Reference Guide. Skybox Risk Control version

164 Skybox Risk Control User s Guide 3 (For advanced users) To configure additional settings, click next to Advanced. Note: Queries created in the Access Analyzer are intended for one-time use only. A query cannot be reused once you create a different query or close the Access Analyzer. To analyze a query After filling the query fields, click. The Access Analyzer analyzes access between the source and the destination. The results of the analysis are shown in the results tree. Note: If you change any input parameters after analyzing the query, reanalyze the query for the changes to take effect. Defining the source and the destination The source and destination of access queries are defined by their scope and the services on which access is to be verified. The destination may have other defining information (see page 167). Defining the scope The scope of the source specifies the source points for access analysis; the scope of the destination specifies the destination points for access analysis. The scope of either may include: Simple entities, such as single assets or networks Container entities (locations, asset groups, and Business Asset Groups) A mixture of simple entities and container entities The value Any This value is used in the source when analyzing which source points can access a specific destination. This value is used in the destination when analyzing which destinations can be reached from the specified source point. Skybox Risk Control version

165 Chapter 25 Access Analyzer To use the Source and Destination Scope dialog box 1 Click the Browse button next to one of the Scope fields. Figure 57: Source and Destination Scope dialog box The default scope for both source and destination is Any. You must define a specific scope for at least one of them; Skybox View does not verify access from Any to Any. 2 Define the source and destination scopes (as explained in the following procedures). 3 Click OK. To define the source scope 1 To use specific entities in the source scope: In the Available Entities field, select all entities that should be part of the scope and click to move them to the Selected Source field. Note: When querying from a network or a location containing networks, access is analyzed using the IP address ranges of the networks rather than each asset within the networks. To analyze access using routing rules or access rules on specific assets, select the assets rather than selecting the networks containing the assets. 2 To use IP address ranges in the source scope: a) Click IP Ranges (in the Source area). b) Do one of the following: Figure 58: Use IP Ranges area of Scope dialog box Type an IP address range (or single IP address) directly in the Use IP Ranges field Click the Browse button next to the Use IP Ranges field to select IP address ranges c) If you are using a single IP address or address range and you want to include the entity to which the IP address range belongs, click Find Networks. Select a matching network and click Select. When an entity is selected and alternate IP address ranges are specified, the analysis starts from the selected entities, but the alternate IP addresses are used instead of the entity s IP addresses. Skybox Risk Control version

166 Skybox Risk Control User s Guide Note: If you specify IP address ranges without selecting at least one Source entity, you must select at least one entity in Destination Scope. In this case, the specified IP addresses are used as source addresses for analyzing access to the selected Destination entity. To define the destination scope 1 To use specific entities in the destination scope: In the Available Entities field, select all entities that should be part of the scope and click Destination field. 2 To use IP address ranges in the destination scope: a) Click IP Ranges (in the Destination area). to move them to the Selected b) Do one of the following: Figure 59: Use IP Ranges area of Scope dialog box Type an IP address range (or single IP address) directly in the Use IP Ranges field Click the Browse button next to the Use IP Ranges field to select IP address ranges c) If you are using a single IP address or address range and you want to include the entity to which the IP address range belongs, click Find Networks. Select a matching network and click Select. Defining the services By default, access between the source and destination is verified on all available services. However, you can define specific services on which access is verified for the source or the destination. When specific services are defined, access is verified only on those services, rather than on all available services. To define specific services through which access is checked 1 (To define services for the source) Click in the Source area. The Services field appears in the dialog box. Skybox Risk Control version

167 Chapter 25 Access Analyzer 2 Click the Browse button next to the Services field. Figure 60: Services dialog box By default, the Available Services list is sorted by ports. To sort it alphabetically, click. By default, common service families are shown. To show all service families, click. 3 In the Services dialog box, do any of the following: In the Available Services field, select the desired source or destination ports and click to move them to the Selected Services field. Click the Browse button next to the Additional Services field to define additional ports to use when checking access. 4 Click OK. 5 To use all services except those selected, select NOT. Additional destination options Figure 61: Services field Usually, you use the default destination Scope field to define the destination scope a collection of assets or networks that should be reached by all packets. You can also define a Sending To scope, consisting of IP address ranges. All IP addresses in the ranges you define in the IP Ranges field are used as destination addresses at the beginning of the access analysis, before network address translation is performed. Services specified in the related Services field are handled similarly. Note: When you define Sending To parameters, the default destination Scope and Services fields are referred to as the Arriving At scope and services. Skybox Risk Control version

168 Skybox Risk Control User s Guide For example, Internet is selected as the source Scope, no destination Scope is selected, and the destination IP Ranges field is set to This query means What networks, assets, and services are reached if a packet with a destination in the IP address range to is sent from the internet? If you select Arriving At entities and Sending To ranges, access is analyzed using the selected IP address ranges, but only the selected entities are shown (that is, the selected entities filter the results). To use the additional destination options 1 In the Access Query pane, click to expand the Destination area. The original destination scope and services are now shown in the Arriving At area and another area, Sending To, appears in the dialog box. 2 Click the Browse button next to the IP Ranges field. Figure 62: IP Ranges dialog box 3 In the IP Ranges dialog box, for each IP address range to be used, click Add, type the IP addresses of the range and click OK. 4 If necessary, define specific services through which access should be checked: a) Click the Browse button next to the Sending To Services field. b) In the Services dialog box, do any of the following: In the Available Services field, select services and click to move them to the Selected Services field. Click the Browse button next to the Additional Services field to define additional destination services to be used when checking access. c) Click OK. d) To use all services except those selected, select NOT. Skybox Risk Control version

169 Access Analyzer output Chapter 25 Access Analyzer The results of the analysis are displayed as a tree in the Results pane (top right) of the Access Analyzer. Use the display filters (see page 169) at the top of the pane to define how the results are displayed in the tree. Detailed information for specific access routes is displayed in the Access Route pane (bottom right). Display filters Figure 63: Access Analyzer - results The toolbar at the top of the Results pane contains the following display filters: Show: The type of entities to display: Accessible Destinations: The accessible destinations when the specified services are used Blocked Destinations: The destinations for which there are blocked routes from the source when the specified services are used Sources Accessing the Target: The assets that can access the selected destination when the specified services are used Blocked Sources: The assets for which there are blocked routes to the destination when the specified services are used Note: When blocked sources or destinations are displayed in the results tree, all names in the tree are italicized. Group by: Specifies whether to group the entities displayed in the results tree by their services or by their network interfaces. Authentication: No: Non-authenticated traffic Yes: Authenticated traffic Skybox Risk Control version

170 Skybox Risk Control User s Guide N/A (Both): Authenticated and non-authenticated traffic Entities: Model Entities Only: Assets and services that are part of the current model. When these existing entities are hidden, only the IP address and port ranges are shown. Possible IP Ranges: All IP addresses and port ranges that are exposed by firewall access rules, even if they do not exist in the model. Note: The default view displays existing entities. Show / Hide locations: Specifies whether to group networks into locations. Save Results: Save Results as XML: Saves the currently displayed access results as an XML file. Save Results as CSV: Saves the currently displayed access results as a CSV file. Save Route as HTML: Saves the selected access route as an HTML file. : Specifies whether to include the reply route when an Access Route is displayed. Understanding the results Most of the analyses of the Access Analyzer involve connectivity or security. Connectivity queries are used to ascertain whether there is a connection between two points in your organization and to understand the route between them. If there is connectivity between the two points, the Results pane shows you the assets and services that can be connected, and the Details pane shows you how the connection is made. If there is no connectivity, a message to that effect appears in Results pane. Security queries are used to verify access restrictions applied in your organization. For a security query, the accessible results should contain only the assets and services that are allowed to be exposed. If additional assets are present in the results, these assets can also open a connection to the Destination entity. For example, to check that no developers have access to finance information (that is, to computers in the Finance Department), analyze access from R&D to the Finance Department (Source = R&D, Destination = Finance Department). If the accessible results are empty, there is no access (which is what you want). If there are any results, there is undesired access; check the Details pane to find the access path, so that you can fix the problem. Results tree The top pane of the analysis results contains a results tree. Assets (and IP address ranges) are grouped in the tree by location and then by network. You can expand each asset or IP address range to see the relevant services. Figure 64: Access Analyzer - Results tree The contents of the results tree vary according to which display filters (see page 169) are selected. Skybox Risk Control version

171 Chapter 25 Access Analyzer When destinations are shown, you can drill down from a destination asset to see accessible or blocked services on that asset. When source points are shown, you can drill down from a source network to see the gateways that enable or block access. When you select an asset or a service in the results tree, the Details pane that is under the results tree shows all potential routes through which access from the source to the destination is possible for the selected entity. When inaccessible entities are displayed in the results tree, the Details pane shows the blocked routes so that you can see how they are blocked. Canceling analyses and display of details You can cancel any action that causes the Results pane or the Details pane to be refreshed. To cancel analysis Click Cancel ( ) at the bottom of the Results pane. This button is visible only while the Access Analyzer is analyzing results or details. Viewing the access route The Details pane displays the Access Route from the selected source to the destination (or from the source to the selected destination, when displaying results by destination). You can view the route in step-by-step text format or in the Network Map. For each route, the first step is the source and the final step is the destination; all hops are shown. You can use the following controls to determine how the results are displayed: : Enables you to switch between multiple routes. : Determines the display format of the results. : Determines the map in which the route is displayed. Click Show Route Map to display a map of only the selected route. Note: When you switch to a map other than the route map, highlighting of the currently selected route is lost. Switch to a different route or a different result to view the route in the Map pane. : Opens the properties of the route map so that you can change the settings. Skybox Risk Control version

172 Skybox Risk Control User s Guide Viewing the Access Route in text format The following is an example of an access route displayed in text format. Figure 65: Sample Access Route For each route, the source and destination are listed in full outside the table. The table lists the exact route taken. The first step is the source point. If the source point is a subset of the source specified in the Source field, the source IP address ranges are listed. Intermediary steps show gateways passed on the way, with their access rules and address translation rules (if any). Rules are shown with their direction, rule number, ruleset name and rule action (such as Allow or Deny). Each intermediary step includes an inbound rule and an outbound rule. Click the link in a rule to open the Access Control List Editor, where you can view or change the rule easily. When access goes through a VPN tunnel, Encrypted is listed in the step, as well as information about the VPN tunnel. The last point is the destination, including asset name and IP address. For information about inaccessible routes, see Inaccessible entities (on page 173). Skybox Risk Control version

173 Inaccessible entities Chapter 25 Access Analyzer In some cases, the Access Analyzer shows that there is no access from the source to the destination. (This may or may not be the desired outcome of access analysis.) There are two basic reasons why a network or asset is inaccessible: The route is blocked: An access rule denies access between the source and the destination (this is the most common reason). The route is broken: No routing exists from the source to the destination. Use Show Blocked Sources or Show Blocked Destinations to find out why there is no access. Blocked routes When routes between the source and destination are blocked, the Access Route lists all hops from the source to the point where the route is blocked. The last entry in the table shows what is blocking the route usually an access rule on a firewall. The full destination is listed after the table, as in all access routes. In the following example, the route between the Development network and the Finance Servers was checked for access and no access was found. To find out where access is blocked, Show Blocked Destinations is used to show the blocked routes. Figure 66: Example of blocked route The Access Route shows that access is denied (blocked) by the finance FW firewall and that the specific rule used is access rule 6. Skybox Risk Control version

174 Skybox Risk Control User s Guide Broken routes When an entity is inaccessible for routing reasons (for example, some of your organization s routers are missing in the model), the route is not blocked, but rather broken (incomplete). This may happen when: The source knows the destination by a different name or IP address (because of NAT rules). The model is incomplete and gateways that connect between the source and the destination are missing. Routing rules are missing in gateways between the source and the destination. There is a route to a null (black hole) in a gateway between the source and the destination. When a route is broken, the Access Route provides an explanation of what happened, as in the following example. Saving the results Figure 67: Broken route You can save the results of access analysis in three different formats, depending on what you need: As a CSV file This saves a list of the source-destination-port combinations through which the specified access can be achieved, as in the following example. Source Destination Service Authenticated /20-21/TCP; /53-53/TCP; /79-80/TCP; / /TCP; / /TCP; / /TCP; /20-21/TCP; /53-53/TCP; FALSE FALSE Skybox Risk Control version

175 Chapter 25 Access Analyzer As an XML file /79-80/TCP; / /TCP; / /TCP; / /TCP This saves the results tree as an XML file, as in the following example. - <ExplainTree> - <Location name="us"> - <Location name="new York"> - <Network name="dmz [ / 24]" count_description="256 IPs;6 TCP/UDP ports"> - <IpRange name=" " count_description="256 IPs; 6 TCP/UDP ports"> <PortRange name="21 (TCP)" count_description="0 IPs" /> <PortRange name="25 (TCP)" count_description="0 IPs" /> <PortRange name="53 (TCP)" count_description="0 IPs" /> <PortRange name="80 (TCP)" count_description="0 IPs" /> <PortRange name="443 (TCP)" count_description="0 IPs" /> <PortRange name="53 (UDP)" count_description="0 IPs" /> </IpRange> </Network> </Location> </Location> </ExplainTree> A specific route as an HTML file This saves the route displayed in the Details pane as an HTML file, as in the following example. Figure 68: Save Route to HTML Skybox Risk Control version

176 Chapter 26 Adjusting the security metrics parameters You can adjust the default values of many security metrics parameters to suit the needs of your organization. This section explains: How the security metrics analysis is done. The parameters that may need changing and how to change them. You access standard parameters from the GUI, while advanced parameters are only accessible in a file under the Skybox View directory. In this chapter Calculation of scores for Vulnerability Level Indicator security metrics Calculation of scores for Remediation Latency Indicator security metrics Impact levels Additional security metrics parameters Calculation of scores for Vulnerability Level Indicator security metrics The Vulnerability Level Indicator (VLI) measures the average rate of vulnerability occurrences residing on assets in a group of assets, such as a Business Asset Group or Business Unit. In simple terms, the rate is the average number of vulnerability occurrences per asset. However, because vulnerability definitions differ in their criticality, the vulnerability occurrences are weighted in the computation. vli_weight(v) = severity_weight(v) The severity weight is a configurable numeric value associated with the different severity levels; the default values are: Critical=1, High=0.3, Medium=0.03, and Low=0 (ignored) three high-severity and three medium-severity vulnerability occurrences on an asset are considered as one critical equivalent vulnerability occurrence. The VLI value of an asset is obtained by adding together the weights of all vulnerability occurrences on that asset. The VLI value is then mapped to a score between 0 and 100 and to a level. You can configure the score mappings for each security metric separately from the Manage Security Metrics dialog box. The VLI value for a group of assets, such as a Business Asset Group, is the average vli_weight per asset. VLI calculation for a sample Business Asset Group A sample Business Asset Group consisting of five assets with their associated vulnerability occurrence counts is presented in the following table. Asset Critical occurrences High occurrences Medium occurrences asset asset asset asset Total occurrences on asset Skybox Risk Control version

177 Chapter 26 Adjusting the security metrics parameters asset Average per asset The VLI value for this Business Asset Group (that is, the average number of critical-equivalent vulnerability occurrences per asset) is about 2.6. When this VLI value is mapped to a VLI score, the VLI score is about 46 (which corresponds to the medium level and to the color ). For additional information about the mapping, see Initial customization (on page 36). Note: You can include the value of Business Impacts and Regulations in the vulnerability occurrence weight formula. For additional information, see Advanced properties (on page 180). Calculation of scores for Remediation Latency Indicator security metrics The Remediation Latency Indicator (RLI) measures the rate of over-due vulnerability occurrences on an asset, based on remediation SLA criteria. The RLI score for an asset indicates the number of over-due or relatively old vulnerability occurrences found on the asset, where each vulnerability occurrence is weighted by a penalty. This penalty takes into consideration both the remediation priority of the vulnerability occurrence and its delay, with high priority vulnerability occurrences that have long delays being assigned the highest weight. The RLI score for a Business Asset Group is the average of the RLI scores for all the assets in the Business Asset Group. The RLI metric enables you to identify hot-spots (such as asset groups or specific vulnerability definitions) whose remediation latency is relatively high, so that you can examine trends in remediation by how quickly the vulnerability occurrences are being fixed. Some parameters used for the RLI calculation (Vulnerability Occurrence Age and SLA time) are defined per security metric in the Security Metric Properties dialog box. The following parameters are defined globally for all Remediation Latency Indicator-type security metrics, and are located in the sb_server.properties file: Parameter Definition In properties file as Remediation Priority The importance of remediating vulnerability occurrences of this severity level, where: Critical=P1 High=P2 KPI_NO_HOST_IMPACT_VUL_SEVERITY_PRIORITI ES The following value is used by default: P1,P2,P3,NA,NA Latency Penalty Delay period Medium=P3 You can associate each priority LATENCY_PANELTY_P1 LATENCY_PANELTY_P5 with a different latency penalty in The following values are used by default: the RLI formula. Higher priorities typically get higher penalties, LATENCY_PANELTY_P1=1 because the remediation latency LATENCY_PANELTY_P2=0.5 of a higher priority vulnerability occurrence is more severe than LATENCY_PANELTY_P3=0.1 the remediation latency of a lower priority vulnerability occurrence. LATENCY_PANELTY_P4=0 LATENCY_PANELTY_P5=0 The delay in the remediation of a vulnerability occurrence is defined by grace periods, where period 0 indicates no grace period, period 1 indicates a small grace period, and so on. AMOUNT_OF_DELAY_PERIOD_0 AMOUNT_OF_DELAY_PERIOD_3 The following values are used by default: AMOUNT_OF_DELAY_PERIOD_0=0 AMOUNT_OF_DELAY_PERIOD_1=1 Skybox Risk Control version

178 Skybox Risk Control User s Guide The grace period of a vulnerability occurrence is the one that matches its age. The grace periods are defined for the different priorities as a function of their SLA values in days: Period 0 (no delay): 0 days to 1 SLA Period 1 (small delay): 1-2 SLAs AMOUNT_OF_DELAY_PERIOD_2=2 AMOUNT_OF_DELAY_PERIOD_3=3 For example, for an SLA of 30 day: Period 0=0-30 days there is no grace period Period 1=31-60 days Period 2=61-90 days Period 3=91+ days Delay factor Period 2 (large delay): 2-3 SLAs Period 3 (very large delay): 3 or more SLAs The delay factor for a vulnerability occurrence is the latency penalty defined for the vulnerability occurrence according to its priority, multiplied by a factor according to its delay period (small delay low factor; big delay higher factor). The following delay factor are used by default: Period 0=0 Period 1=1 Period 2=1.5 Period 3=2 DELAY_FACTOR_PERIOD_0 DELAY_FACTOR_PERIOD_3. Note: The SLA values provided in the file are default values for all security metrics. Specific values provided in the Manager GUI overwrite these values for existing security metrics. The formula for determining the RLI of a vulnerability occurrence or security bulletin is as follows: rli_weight(v) = latency_penalty(priority(v)) * delay_factor(delay_period(v)) Skybox Risk Control version

179 Examples Chapter 26 Adjusting the security metrics parameters For example, if Critical MS Bulletins must be addressed in 14 days according to your SLA, you must change the Critical SLA in the MS-RLI security metric to 14. If High Importance MS Bulletins must be addressed in 42 days, you must change the High SLA in the MS-RLI security metric to 42. Impact levels Figure 69: Changing the SLA for an RLI-type KPI The asset impact weight is an optional weight. When considered, it is determined by Business Impacts and Regulations. Business Impacts and Regulations specify (for Business Asset Groups and groups of assets) the expected impact level (Very Low to Very High) in case of security loss. DMZ assets and critical servers are typically associated with High or Critical Business Impacts and Regulations, while desktops are usually associated with Very Low or Low Business Impacts and Regulations. Each impact level is mapped into a (configurable) numeric weight. That weight (asset_impact_weight) is then used in computing the vulnerability occurrence weight along with the severity, so that the vulnerability occurrence weight formula is: vli_weight(v) = severity_weight(v) * asset_impact_weight(h) By default, Skybox View does not take impact levels into consideration for security metrics analysis. For the security metrics analysis to include the impact levels, you must: Skybox Risk Control version

180 Skybox Risk Control User s Guide 1 Define the impact levels. Note: When working with Exposure, this step is done as part of building the model. If you are working only with security metrics, see Business Impacts and Regulations (on page 82). 2 Depending on whether the impact levels are to be used for VLI or RLI, set the KPI_VLI_USE_HOST_IMPACT_FACTOR and KPI_RLI_USE_HOST_IMPACT_FACTOR parameters in the sb_server.properties file to true. Additional security metrics parameters The values of the security metrics parameters are in the kpi calculation properties section of <Skybox_View_Home>\server\conf\sb_server.properties. The parameters in the following table may be useful in setting up the behavior of the security metrics. Parameter Default Value Description KPI_SEVERITY_TH RESHOLD KPI_SEVERITY_FA CTOR_FOR_<level >_VULNERABILITY KPI_VLI_USE_HOS T_IMPACT KPI_RLI_USE_HOS T_IMPACT_FACTO R Medium false false The minimum severity of vulnerability occurrences to include in the security metrics analyses. The weight of the different vulnerability occurrence severities in security metrics analyses. Specifies whether to use the impact factor of assets (that belong to Business Asset Groups that have Business Impacts or Regulations) in VLI analyses. Note: If this parameter is set to true, the values of the KPI_HOST_IMPACT_ parameters may need adjusting. Specifies whether to use the impact factor of assets (that belong to Business Asset Groups that have Business Impacts or Regulations) in RLI analyses. Note: If this parameter is set to true, the values of the parameters in the relevant only for RLI section of this file may need adjusting. After changing the value of any of these parameters, the Server must be restarted for the changes to take effect. Skybox Risk Control version

181 Chapter 27 Vulnerability Dictionary The Skybox View Vulnerability Dictionary models the behavior of occurrences of each vulnerability definition in attacks. In this chapter Vulnerability Dictionary information CVE compliance Vulnerability Dictionary information The information for each vulnerability definition in the Vulnerability Dictionary includes: SBV ID: Identification number assigned by Skybox View Existence preconditions: Services that are required on an asset for an occurrence of the vulnerability definition to exist Exploitation preconditions: Preconditions for exploiting an occurrence of the vulnerability definition Exploitation effects: Achievements an attacker could gain from a successful exploitation of an occurrence of the vulnerability definition Attributes: Various attributes that might affect the likelihood for a successful exploitation of an occurrence of the vulnerability definition, including: SBV ID Difficulty: An estimated difficulty level for exploiting occurrences of the vulnerability definition. The difficulty of exploiting a vulnerability occurrence is largely dependent on the existence or nonexistence of known exploit code for exploiting the vulnerability definition, or a detailed description of how to exploit it. Commonality: An indication of how frequently attackers exploit this vulnerability definition. In the Vulnerability Dictionary, each vulnerability definition is defined on a single service; if similar vulnerability definitions exist on several services, they are usually defined as different vulnerability definitions with different ID numbers. Note: If a vulnerability definition is defined on several services with the same ID by CVE and various scanners, the Vulnerability Dictionary also defines it as a single vulnerability definition with a single ID. Exploitation preconditions Exploitation preconditions define two values: The access that the attacker must have to exploit occurrences of the vulnerability definition The authentication required on the attacked service: Whether the attacker must first pass the service authentication requirement to exploit occurrences of the vulnerability definition Skybox Risk Control version

182 Skybox Risk Control User s Guide The following are examples of exploitation preconditions: Remote Access without Authentication: The attacker has remote access to the service on which the vulnerability occurrence resides and no authentication is required to successfully exploit the vulnerability occurrence. Most attackers can gain access to most vulnerable services. Local Access with Authentication: The attacker has some type of local control over the vulnerable asset. This precondition is typical for vulnerability occurrences that enable privilege escalation on an attacked asset. The remote access precondition has several variations that should be modeled. For example, for some DoS attacks, it is sufficient for the attacker to have a one-way UDP connection to the vulnerable service. The limited requirement for one-way access in this case could enable an attacker to create spoofing attacks that succeed in passing through firewalls and arrive at the vulnerability occurrence because of its spoofed source IP address. Exploitation effects Exploitation effects formally describe the achievements that an attacker could gain from successful exploitation of a vulnerability occurrence. Achievements include: DoS: The attacker could cause a denial of service to the attacked services on the asset. User Control: The attacker could gain user (non-root) control on the attacked asset. Root Control: The attacker could gain root control on the attacked asset. File System Read: The attacker could read arbitrary files residing on the file system of the attacked asset. Information Leakage: The attacker could cause various types of information leakage, including leakage of user names, passwords, and source code. During attack simulation, a vulnerability occurrence can be exploited only if all of its preconditions are matched. In a multi-step attack, achievements gained by exploiting one vulnerability occurrence help to fulfill the preconditions of the next vulnerability occurrence. The Vulnerability Dictionary is continuously updated by the Skybox View content team. It models all new vulnerability definitions as they are released and updates existing vulnerability definitions throughout their life cycle. The dictionary can be configured (by Admins) for automatic update to enable you to keep your security model up-to-date. Severity The severity of a vulnerability occurrence in Skybox View is based on the CVSS (Common Vulnerability Scoring System) base score, a standard rating system for vulnerabilities (from 1 to 10). The values for the CVSS fields are filled using the exploitation preconditions and exploitation effects of the vulnerability definition. If any of this information is not available in the dictionary, the severity is set using an average of CVSS or severity values from external sources. Skybox View supports CVSS version 2. The CVSS base score is also translated to a scale (Critical, High, Medium, Low, or Information), and the severity is displayed in Skybox View as a scale value followed by the actual score. External catalogs The Vulnerability Dictionary also supports most common external vulnerability catalogs. For each vulnerability definition in the Vulnerability Dictionary that also appears in external catalogs, Skybox View can display the catalog names and IDs of the vulnerability definition in the external catalogs. The following catalogs are supported: Adobe CVE Skybox Risk Control version

183 Chapter 27 Vulnerability Dictionary Cisco PSIRT FoundStone IBM ISS Microsoft bulletins ncircle Nessus Oracle Qualys Retina SecurityFocus (BID) Rapid7 CVE compliance Common Vulnerabilities and Exposures (CVE ) is a dictionary of common names (that is, CVE identifiers) for publicly known information security vulnerability definitions. CVE is the industry standard for vulnerability and exposure names. CVE s common identifiers make it easier to share data across separate network security databases and tools, and provide a baseline for evaluating the coverage of an organization s security tools. When information from one or more of Skybox View s external sources incorporates CVE identifiers for vulnerability definitions, this information is added to the information in the Skybox View dictionary. CVE updates are also incorporated into the Skybox View dictionary as they are released. To ensure CVE compliance, the Vulnerability Dictionary includes a single vulnerability definition (that is, a single SBV ID) for every CVE ID. The SBV ID can also include IDs from scanners and other dictionaries, such as Security Focus. There are also vulnerability definitions for which no CVE ID is defined: if a vulnerability occurrence of one of these vulnerability definitions is reported by a scanner that is supported by Skybox View, it is assigned an SBV ID. If a CVE ID is assigned to one of these vulnerability definitions later, the CVE ID is then added to the vulnerability definition s data in the Vulnerability Dictionary. Skybox Risk Control version

184 Chapter 28 IPS support in Skybox View This section explains how to model and use intrusion prevention system (IPS) devices in Skybox View. IPS devices are used by organizations to reduce the risk of cyber attacks. In Skybox View, you can represent IPS devices in the network model and the effect of these IPS devices in the model is used when simulating potential attacks. Currently, Skybox View directly supports the following IPS devices: IBM Proventia G Appliance HP TippingPoint Palo Alto Networks (firewalls with IPS capacity) You can model other devices manually or using Skybox View s Integration XML (ixml) format. In this chapter IPS dictionary Working with IPS in Skybox View IPS dictionary The IPS rules (issue IDs) of support IPS devices are included in the Skybox View Dictionary. The rules are modeled by associating each rule with the vulnerability definitions that it handles. Note: Only signature rules that handle specific vulnerability definitions are modeled. Rules that identify and handle more general packet anomalies are currently not modeled. Dictionary updates include updates of vendor IPS rule definitions. Working with IPS in Skybox View This section explains how to: Add supported IPS devices to your model Validate supported IPS devices View and manage IPS devices in Skybox View Simulate the effects of IPS devices Add other types of IPS devices to your model Use Skybox View to test What If scenarios involving IPS devices Adding supported devices Adding an IPS device to Skybox View involves the following steps: Collect the device data Skybox Risk Control version

185 Chapter 28 IPS support in Skybox View IBM Proventia G appliances: Use IPS ISS SiteProtector IPS Collection tasks (see IBM SiteProtector IPS collection tasks, in the Skybox View Reference Guide) HP TippingPoint IPS devices: Use IPS HP TippingPoint Collection tasks (see HP TippingPoint collection tasks, in the Skybox View Reference Guide) Palo Alto Networks firewalls: Use Firewalls Palo Alto Networks Collection tasks, or by collecting the data offline (see Palo Alto Networks firewall, in the Skybox View Reference Guide) For Layer 2 devices: Configure the network interfaces (on page 185) Note: The network interfaces of L3 devices are automatically connected. Configuring the network interfaces of L2 devices After collecting the device data, the new device in Skybox View has several pairs of L2 network interfaces and one management (L3) network interface. Each pair of L2 interfaces connects the IPS device to a different network. Each interface of a pair connects one side of the network to the IPS device. In Skybox View, this is modeled by splitting the network into segments (manually) and manually attaching each L2 interface to the appropriate network segment. The L3 interface is attached automatically to its network (if the network exists in the model). To configure the network interfaces in Skybox View 1 Find out which networks (lines) are monitored by the IPS device and which network is monitored by which pair of adaptors (network interfaces). 2 For each network that the IPS device monitors, create two network segments: one for each endpoint of the line (that is, one for each network interface). To create network segments: a) In the Model tree, right-click the network to be segmented and select Manage Segments. Figure 70: Manage Network Segments dialog box Skybox Risk Control version

186 Skybox Risk Control User s Guide b) Click Add. Figure 71: New Segment dialog box c) Type a Name for the segment and click OK. d) Repeat steps b and c for the second segment. 3 Assign each necessary L2 interface to its corresponding network segment: a) In the tree, select All Network Devices > IPS Devices. b) In the Table pane, select the IPS device. Skybox Risk Control version

187 Chapter 28 IPS support in Skybox View c) In the Network Interfaces tab of the Details pane, right-click the interface to be connected and select Properties. Figure 72: Network Interface Properties dialog box d) In the Network field, select the network segment to which to attach the interface. e) Click OK. When this IPS device is updated using the task, the connection between the L2 interfaces and their network segments is created automatically. Terminology for working with IPS devices Skybox View works with devices from many vendors and does not use vendor-specific terminology when modeling the devices. However, since the terms may be confusing, Skybox View terminology for IPS is mapped to IBM (Proventia G) and HP (TippingPoint) terminology in the following table. Skybox View term IBM term HP TippingPoint term Asset of type IPS with Firewall Type set to TippingPoint or ISS Proventia Proventia G appliance IPS rule group Protection domain Profile IPS rule Security event Filter Rule ID Issue ID (ID of the security event) TippingPoint device Filter number (Network) interface Adaptor Segment Validating IPS devices in the model After you add an IPS to your model, validate that it was modeled correctly using the techniques explained in the following sections. Skybox Risk Control version

188 Skybox Risk Control User s Guide Validating the IPS rules After you import an IPS device and (for L2 devices) attach every network interface to the correct segments or networks, validate that the IPS rules were imported correctly. To validate the IPS rules 1 In the Table pane, right-click the device and select Manage IPS Rule Groups. 2 Double-click each rule group to view its rules. 3 Verify that the rules appear in the dictionary (that is, a check mark appears in the Dictionary column of the table). If many of the rules are not in the dictionary, you might be using an outdated version of the Skybox View dictionary. (If only a small number of rules are not in the dictionary, they may be custom-defined on the device.) For information about updating your Skybox View dictionary, see the Dictionary updates chapter in the Skybox View Installation and Administration Guide. 4 Verify that the rule groups of the device in Skybox View match the rules groups of the actual device. Note: For Proventia G appliances, you can find the device rules and their rule group (protection domain) in SiteProtector, in the Security Event section. You can also view the IPS rule groups and rules in the Details pane, in the IPS Rule Groups tab. Validating the access rules RC After you validate the IPS rules, validate that the access rules were imported correctly. To validate the access rules 1 In the Table pane, right-click the device and select Access Rules. 2 In the Access Control List Editor, verify that there are two rule chains: ACCESS and IPS. 3 Verify that access rules in the ACCESS chain do not allow packets to move between different lines (networks) that are monitored by the IPS or between the management (L3) interface and the L2 interfaces. Note: For supported devices, these rules are generated automatically during the collection and should be checked briefly. However, this step is very important for devices defined using the GUI or ixml. 4 Verify that the (IPS) access rules in the IPS chain contain references to IPS rule groups. Verifying the effects of the IPS device When an attack path attempts to goes through an IPS device, it is prevented (or has a lower probability of success) if it matches a preventing IPS rule. After verifying that the IPS device was imported correctly, verify that Skybox View correctly simulates the effect of the IPS device on the risk levels of your network. Vulnerability occurrences that become inaccessible as a result of IPS prevention rules are assigned the Protected exposure status (rather than Inaccessible). Note: There is no special status to show whether a vulnerability occurrence became indirectly exposed as the result of an IPS prevention rule or an access rule on a non-ips gateway, or whether a vulnerability occurrence is partially prevented by IPS devices (from some of the Threat Origins or in some of the access routes). Skybox Risk Control version

189 To verify the effects of the IPS device Chapter 28 IPS support in Skybox View 1 If necessary, enable the IPS device (in the Table pane, right-click the device and select Enable IPS). 2 Run the Analyze Exposure task. In the Analyses tree (Public Analyses > Vulnerabilities > By Exposure > Protected), check whether any exposed vulnerability occurrences (of the vulnerability definitions that the IPS device is configured to prevent) became Protected or Indirect. Note: In many cases, the IPS is supposed to protect a vulnerability occurrence from only one Threat Origin (such as the internet) or one Threat Origin Category (such as External). The following procedure explains how to check this. 3 As an additional check, disable the IPS device (right-click the device and select Disable IPS), simulate attacks again, and check whether the exposure status of the relevant vulnerability occurrences changes back to Exposed. Verifying the effects of an IPS device against a threat If the IPS device is supposed to protect against one Threat Origin Category (such as External) only, the vulnerability occurrences that it blocks may be vulnerable to other Threat Origin Categories and they will not have the Protected exposure. However, you can check the exposure of these vulnerability occurrences to the specific Threat Origin Category. To verify the effects of the IPS device against a single Threat Origin Category 1 Open a vulnerability occurrences analysis that contains the vulnerability occurrences to be blocked by the IPS device. 2 Add the <Category_name> Exposure field to the displayed columns for this table (right-click in the header row of the table and select Customize Current View). 3 Check whether the status of the desired vulnerability occurrences in the new column is Protected. Figure 73: Exposed vulnerabilities - protected against external threats Note: If there are several Threat Origins in the Threat Origin Category and you are only interested in one of them, temporarily disable the irrelevant Threat Origins, rerun the attack simulation and repeat steps 1 through 3. Viewing and managing IPS devices in Skybox View The Model tree (All Network Devices > IPS Devices) contains a list of all IPS devices in the model. IPS devices are modeled using: IPS rules and rule groups IPS access rules, which define the scope (source, destination, service, and so on) of each rule group Note: Firewalls with supported IPS capability, such as Palo Alto Networks firewalls, are shown in All Network Devices > Firewalls. Skybox Risk Control version

190 Skybox Risk Control User s Guide Working with IPS rules and rule groups To access the IPS rules 1 In the Table pane, right-click the IPS device and select Manage IPS Rule Groups. Figure 74: Manage Host IPS Rule Groups dialog box 2 Double-click an IPS rule group or select the group and click Modify. Figure 75: FTP Rule Group Properties dialog box IPS rules are configured to either prevent (block) or detect (log, send message, and so on) malicious packets. You can add, delete, and modify IPS rules. When adding new rules, you can: Search for vendor-specific rules in the Skybox View Dictionary and add them to an IPS rule group (see Adding new vendor-defined IPS rules (on page 191)). Define completely new rules and specify which vulnerability definitions they should act upon (see Adding custom IPS rules (on page 192)). Working with access rules To access the access rules for the IPS device In the Table pane, right-click the IPS device and select Access Rules. Each IPS device has at least two rule chains: IPS and ACCESS. Skybox Risk Control version

191 Chapter 28 IPS support in Skybox View In the IPS chain, each access rule relates to a specific rule group (in Proventia, each rule group represents a protection domain). The rules are of type IPS. There are usually two rules for each rule group: one inbound and one outbound. IPS access rules include the regular scope parameters (source, destination, and network interfaces) and a reference to one of the device s IPS rule groups. The ACCESS chain may include rules generated by Skybox View or by a user to ensure the correct flow of packets through the device, and access rules imported from the device (if it has filtering capabilities). Note: For Proventia G appliances, access rules are currently not imported from the device. The rules in the ACCESS chain are generated automatically according to the configuration of the device. They ensure the correct flow of data packets through the device: preventing packets from moving between L3 and L2 interfaces and between different lines (networks) monitored by the device. For additional information about working with access rules, see the Access Control List Editor chapter in the Skybox View Reference Guide. Adding new vendor-defined IPS rules You can add any vendor-defined rule that is included in the Skybox View Dictionary to an IPS rule group. Note: Vendor-defined rules that you add must match the device type. To add vendor-defined rules to an IPS rule group 1 In the Rule Group Properties dialog box, click Add. Figure 76: Add Vendor IPS Rules dialog box Skybox Risk Control version

192 Skybox Risk Control User s Guide 2 Define search parameters in the Search Parameters pane. You can search for rules using: A string in the rule title The vendor rule ID The string at the beginning of the Vendor Rule ID field is included automatically based on the vendor catalog used by the device. For IBM Proventia G appliances, the string is ISS_IPS/. Vulnerability definitions 3 To search for rules that handle a specific vulnerability definition, click the Browse button next to the Vulnerability Occurrence field. Use the Vulnerability Definition Finder dialog box to select the vulnerability definitions to block. 4 Click Search. The results of the search appear in the Search Results field. 5 Select rules in the Search Results field and click to move them to the Selected Rules field. 6 Select the action that this rule takes when it encounters vulnerability occurrences of these vulnerability definitions. The default action is Prevent. You can model detection rules but they are not used in attack simulation. 7 Click OK to add the new rules and close the Add Vendor IPS Rules dialog box. Adding custom IPS rules You can add custom rules to an IPS rule group by specifying the rule and the vulnerability definitions on which the rule acts. To add a custom rule to an IPS rule group 1 In the Rule Group Properties dialog box, click Add Custom. Figure 77: New IPS Rule dialog box 2 In the General tab, fill in the following fields: Title Action Skybox Risk Control version

193 Severity (Optional but recommended) Description 3 If you do not want the rule to be used when analyzing risk, select Disabled. Chapter 28 IPS support in Skybox View Note: All other fields are disabled either because they cannot be edited using the Rule Group box or because they are applicable only for vendor IPS rules. 4 Click the Vulnerability Occurrences tab. 5 Click Add. Figure 78: Add Vulnerabilities dialog box This dialog box is like the Vulnerability Definition Finder dialog box. 6 Fill in the search fields and click Search. The results appear in the Search Results field. 7 In the Search Results field, select the vulnerability occurrences on which this IPS rule is to act and click to move them to the Selected Vulnerabilities field. 8 Click OK. The selected vulnerability definitions are added to the list of vulnerability definitions for the IPS rule. 9 Click OK to save the new rule. Skybox Risk Control version

194 Skybox Risk Control User s Guide Simulating the effects of IPS devices The Analyze Simulate Attacks task takes enabled IPS devices into account when ascertaining possible attacks and the security risks. An attack action is considered prevented if the access routes required for the action are blocked by IPS devices. More specifically, an attempt to exploit remotely from source x to vulnerability occurrence v on destination y is considered as prevented if: The access route from the source to the destination necessarily passes through an IPS device The device is configured to block attack attempts on vulnerability occurrence v (for sources and destinations that include x and y) Note: Only IPS prevention rules are used in attack simulation. Detection rules are not used. Vulnerability occurrences that become inaccessible as a result of IPS prevention rules are assigned the Protected exposure status (rather than Inaccessible). For additional information about the effects of IPS devices on vulnerability occurrences and risk, see Verifying the effects of the IPS device (on page 188). To simulate the effects of IPS devices 1 Enable all IPS devices that you are using in attack simulation. (To enable an IPS device, right-click the device and select Enable IPS.) 2 Run the Analyze Exposure task. Additional ways to model IPS devices You can model IPS devices that are not supported directly by Skybox View using the GUI or ixml. Defining an IPS device involves the following steps: 1 Create an IPS device in the model. 2 Assign the network interfaces of the IPS device to network segments in the model. 3 Create IPS rule groups with the appropriate rules. 4 Create IPS access rules. 5 Create any other necessary access rules. Defining IPS devices using the GUI You can define IPS devices manually using the Skybox View GUI. You can use this method to define IPS devices that are directly supported by Skybox View as well as IPS devices that are not currently supported (custom devices). Creating an IPS device in the model An IPS device is modeled as an asset of type IPS. To create an IPS device 1 In the Model tree, expand All Network Devices. 2 Right-click IPS Devices and select New IPS. 3 In the New Asset dialog box: a) Type a Name for the IPS device. b) Do one of the following: For IBM Proventia appliances: In the Firewall Type field, select ISS Proventia. For HP TippingPoint devices: In the Firewall Type field, select TippingPoint. Skybox Risk Control version

195 For custom devices: In the Firewall Type field, select Custom. c) Fill in required fields: Select Layer 2. In the Network Interfaces field, define the device s network interfaces. Chapter 28 IPS support in Skybox View (Optional but recommended) Select values for the Operating System and Platform fields. The default values in all other fields do not need to be changed. d) Click OK. Configuring the network interfaces After you add the device to the model, you must assign the network interfaces in the model to the correct networks. To configure the network interfaces 1 Find out which networks (lines) are monitored by the IPS device and which network is monitored by which pair of adaptors (network interfaces). 2 For each network that the IPS device monitors, create two network segments: one for each endpoint of the line (that is, one for each network interface). 3 Assign each L2 interface to its corresponding network segment. For more detailed instructions, see Configuring the network interfaces (on page 185). Creating IPS rule groups In Skybox View, each IPS rule group monitors a different type of event. Each rule in the group defines one type of event to block. To create an IPS rule group and IPS rules 1 In the Table pane, right-click the device and select Manage IPS Rule Groups. 2 In the Manage Host IPS Rule Groups dialog box, click Add. 3 In the New IPS Rule Group dialog box: a) Type a Name for the rule group. b) Add IPS rules as necessary: To add custom rules (for all types of IPS devices), see Adding custom IPS rules (on page 192). To add vendor-defined rules (for IBM Proventia appliances), see Adding new vendordefined IPS rules (on page 191). Creating access rules An IPS device needs access rules of (at least) two types: IPS: Access rules that define the scope of the IPS rule group There must be at least one IPS access rule for each IPS rule group or one for inbound traffic and one for outbound traffic. The action of these access rules must be IPS. ACCESS: Access rules that define the movement of packets in the device. Define rules so that packets cannot move between different lines (networks) that are monitored by the IPS device nor between the management (L3) interface and the L2 interfaces. For additional information about access rules, see Access Control List Editor, in the Skybox View Reference Guide. Skybox Risk Control version

196 Skybox Risk Control User s Guide Order of applying IPS access rules in IPS devices The IPS access rules in a rule chain are applied in one of two ways, depending on the predefined behavior of the device: Use all rules that match the data. This is the method that is usually used for IPS access rules. Use (only) the first rule that matches the data. This is the method used for access-related access rules but it is not often used for IPS access rules. For supported IPS device types (such as IBM Proventia), the method used is according to the behavior on the device and cannot be changed. For device types that are not directly supported that is, devices whose Firewall Type is set to Custom the Use all rules that match the data method is used by default. To change the method of applying IPS access rules for a custom IPS device 1 Open the Properties dialog box for the device. 2 Click the Browse button next to the Firewall Type field (where Custom is selected). Figure 79: ACL Management dialog box 3 In the ACL Management dialog box, in the Applied IPS Rules field, select a behavior: First matching scope Any matching scope Defining IPS devices using ixml Skybox View supports definition of IPS devices using the ixml file format. You can use ixml to define IPS rule groups, IPS rules and the vulnerability definitions they handle, and IPS access rules that define the scope of the IPS rule groups and then import the ixml file into the model. Skybox Risk Control version

197 Chapter 28 IPS support in Skybox View You can create ixml files manually or by using Perl scripts to translate the mapping and configuration files of unsupported IPS devices to ixml. To model IPS devices using ixml, see the following in the Skybox View Developer s Guide: ixml elements: For general information about ixml elements Example of ixml code for an IPS device: For a sample ixml code for an IPS device AddIpsRuleGroup method: For information about Perl script API methods for supporting IPS devices Testing the effects of an IPS device using Skybox View You can experiment with different IPS device setups in your network using the What If model. Testing new IPS devices You can use Skybox View to simulate the effects of an IPS device at a location in your network to establish whether an IPS device at that location would improve network security. After you add the device, you can create custom rules (or add vendor-defined rules from the Skybox View Dictionary) that handle the problems that you are addressing, such as critical web server vulnerability definitions. You can then check whether the IPS device lowers the risk and risk of attack on the network. To test a new IPS device 1 If you do not have a What If model: Select File > Models > Create Model. 2 In the Source Model drop-down list, select Live. 3 In the Target Model drop-down list, select What If. 4 Select Switch to target model after creation. This copies the current Live model to the What If model and switches to the What If model. 5 Add the IPS device to the What If model using one of the following methods: A collection task (on page 184) The GUI (on page 194) ixml (on page 196) 6 Run a task of type Analysis - Exposure to simulate attacks. 7 Check the results of the attack simulation (see page 188). Testing enhanced coverage of an IPS device If an IPS device has limited coverage of vulnerability definitions in Prevention mode, you can explore the effects of adding rules to cover additional vulnerability definitions. For example, you can create custom rules (or add vendor-defined rules from the Skybox View Dictionary) that handle the problems that you are addressing, such as critical web server vulnerability definitions. You can then check whether the new rules lower the exposure of the vulnerability definitions and the risk of attack on the network. To test enhanced coverage of an IPS device 1 Do one of the following: If you have a What If model: Select the IPS device in the Live model. Right-click the device and select Advanced > Copy To > What If. Switch to the What If model. This copies the IPS device to your What If model. Skybox Risk Control version

198 Skybox Risk Control User s Guide If you do not have a What If model: Select File > Models > Create Model. In the dialog box, select Live as the Source Model and What If as the Target Model and then select Switch to target model after creation. Click OK. This copies the current Live model (including the IPS device) to the What If model and switches to the What If model. 2 In the IPS device in the What If model, create the necessary custom rules (see page 192). For IBM Proventia appliances, you can add vendor-defined rules (see page 191). 3 Simulate attacks. 4 Check the results of the attack simulation (see page 188). Skybox Risk Control version

199 Chapter 29 Optimization This section explains how to optimize attack simulation and access analysis, which are resourceintensive operations. In this chapter Performance considerations Optimizing Access Analyzer analysis Performance considerations Simulating attacks is a resource-intensive operation. This section discusses some performance considerations that you must be aware of when running attack simulation and the Access Analyzer. Performance considerations can be grouped into the following categories: Model size and complexity Routing rule issues Hardware issues Model size and complexity Attack simulation performance is affected by the size and complexity of the model. The more assets, access rules, and vulnerability occurrences that there are in the model, the longer it takes to run attack simulation. (This does not mean that you should not model your whole corporate network, but be aware that as the size of the model grows for example, during the building stages attack simulation takes longer to run.) The number of Threat Origins affects performance; the system may suffer performance degradation when using more than several tens of Threat Origins. To cut down the number of Threat Origins, consider grouping several starting points into one Threat Origin. For example, multiple connections to the internet can be represented as one Threat Origin on the internet cloud. You can also include multiple networks or clouds in one Threat Origin. Setting the Simulate Full IP Spoofing option of the Analyze Simulate Attacks task (or whatever task of type Analysis Exposure that you use) to true greatly slows performance. Routing rule issues Attack simulation works faster when routing rules are collected from the devices than when they are imported from configuration files, as configuration files do not include dynamic routing rules. When the Access Analyzer identifies that routing rules are missing, it assumes that packets to unspecified destinations are forwarded to each of its neighbor routers; this increases the analyses performed by the Access Analyzer (and attack simulation) and also creates false positives. When there are routing rules, the Access Analyzer knows to which of a router s neighbors packets are forwarded. Skybox Risk Control version

200 Skybox Risk Control User s Guide Hardware issues Attack simulation may consume a significant amount of memory on the Server (depends on the size and complexity of the model). To improve performance, make sure that: You are using the recommended hardware setup for your project size (see Server hardware requirements, in the Skybox View Installation and Administration Guide) Your server is properly configured for Skybox View Attack simulation performance benefits from multiprocessors on the Server computer. Note: If you get an Out of Memory warning, attack simulation does not run. Performance considerations for the Access Analyzer The Access Analyzer is not as resource-intensive as attack simulation, but it can be somewhat slow, especially for multiple sources and destinations. Performance considerations that affect attack simulation also affect the Access Analyzer, except the number of vulnerability occurrences (the Access Analyzer does not work with vulnerability occurrences). Setting the Explain Route option of the Access Analyzer to false may improve performance somewhat, but it means that the Access Analyzer only checks if access exists, without any explanation. Optimizing Access Analyzer analysis Access Analyzer analysis is a resource-intensive computational process. It analyzes access routes between the specified source and destination, based on network topology, access and routing rules, address translation, and port translation. Analyses involving a single source asset or network and a single destination asset or network take the least amount of time. Analysis may take longer when: Source or Destination has a value of Any IP address spoofing is used No routing rules exist in the model The source or the destination contains groups of networks or assets Routing rules are completely ignored (Ignore All Routing Rules) or partially ignored (Use Dynamic Routing Rules) Note: When routing rules are not used (because they are ignored or because they do not exist), the analysis results may be less accurate. For large organization networks, this analysis may take some time, because of the large number of assets, networks and gateways involved. The analysis may also be affected by the number of access and address translation rules and by the size of routing tables. Skybox Risk Control version

201 Part V - Planning deployment This part explains how to plan a deployment of Skybox View and prepare the necessary data for the model. It also explains the recommended phases of deployment. Note: All the information in this chapter is relevant when planning a model to use with the Exposure feature of Skybox Risk Control. Some of the information is not relevant when working with the security metrics feature only. Planning deployment Before you begin deployment on a large network, you should create a deployment plan and put together a deployment team from all departments involved in the project. Deployment plan Before you begin deploying Skybox View on a large network, create a deployment plan. This plan should include: The deployment team A list of the people who should be involved in the deployment project, their contact information, and the time required from them. For additional information, see Deployment team (on page 202). A scope for the deployment The parts of the network and the Business Units that the deployment is to cover. The network data needed for deploying Skybox View First, you must understand the structure of your network, by using network diagrams (typically prepared in Visio) and interviewing network administrators. Then you must prepare the network data for Skybox View, including scan results, network diagrams, firewall configuration files, and more. For additional information, see Preparing data for Skybox View (on page 202). A project timeline If this is a large deployment, it is recommended that you divide it into phases, where each phase has a clear value-adding milestone as its endpoint. For additional information, see Phases of deployment (on page 205). The hardware required for deploying Skybox View This includes a dedicated host for the Skybox View Server and, probably, hosts for the Skybox View Collector nodes (not necessarily dedicated). For additional information, see the System requirements section in the Skybox View Installation and Administration Guide. For small networks, a complete plan is not crucial, but greatly facilitates the deployment. At a minimum, a plan for a small network should include the deployment team and the scope of deployment, as much network data as possible, and at least one dedicated host for Skybox View. Skybox Security Professional Services personnel, certified resellers, and implementation partners are trained to assist you in building a deployment plan for your organization. For information about contacting Skybox View, see Technical support (on page 8).

202 Deployment team Deploying Skybox View in a large organization might involve people from several departments, sometimes from different business units, such as: The Security department Typically responsible for managing the security infrastructure within the organization including scanners and other vulnerability assessment tools. The Networking department Typically responsible for managing the network infrastructure within the organization including routers, switches and firewalls. Operations This team should be involved in any organization deployment; they might hold valuable information for the project, such as which networks host the production servers and the primary Business Asset Groups. Business Unit IT owners Usually, you need their consent and approval to deploy a product in their territory. They can also provide you with valuable information about their Business Asset Groups. IT management A risk management project needs the approval of high-level IT management. Obtaining the support and cooperation of these people is important for a quick and successful deployment of Skybox View. It is recommended that you involve them from the early stages of deployment. Some of these people will use the product directly, some will get output (reports and alerts), and some will only provide required information. Those who will use the product might benefit from training. To set up training sessions, contact Skybox Security Professional Services. Preparing data for Skybox View This section explains what data is required for Skybox View and how to prepare it. Information requirements Obtaining all required information is a crucial part of Skybox View deployment. The required information includes: Network information, such as basic architecture and which networks host the production servers. Firewall and router information, such as the credentials needed to access the firewalls and routers. Scanning information, such as which scanners are used and how often the networks are scanned. Business information, such as a list of the most important Business Asset Groups. For worksheets to help you to gather the necessary information, see Worksheets for planning deployment (on page 206). The more information you have ready in advance, the faster your deployment project will go. However, you do not need to wait until you have all of the information to start the deployment; information can also be discovered during the deployment project. The following sections provide details about preparing the necessary information.

203 Preparing a list of network devices When you decide on the scope of the network to include in the model, you must obtain data about each network device in the selected scope. Prepare a list of the network devices in the scope, including all firewalls, routers, and other L3 devices, and all filtering devices (L2 or L3), for example: Type Vendor/version Main IP address Info Owner Comments Firewall FireWall-1 NG Main ISP firewall Firewall Cisco ASA 8.x Internal network firewall Router Router Cisco 76xx IOS 12.x Note: You can use the Device mapping worksheet (on page 207) to help with this phase. Supported data sources The Skybox View platform is compatible with many data sources. The following is a list of some of the most common ones: Firewalls Check Point FireWall-1 NG Check Point Provider-1 NG Cisco PIX/ASA/FWSM Routers Cisco IOS (router) Vulnerability scanners (for importing vulnerability occurrence information) eeye Retina FoundStone FoundScan Enterprise IBM Internet Scanner ncircle IP360 For a complete list of supported data sources, go to Defining the collection strategy You must define a collection strategy for each network device to be modeled. Check the list of supported data sources at to find out which network devices are directly supported by Skybox View. Mark devices that are not supported directly; these must be modeled individually (see Modeling unsupported devices (on page 204)). Skybox View supports the following methods of retrieving data from directly supported devices: Import: Obtain the data from files written by the device. The files might be stored in a repository or they might be stored elsewhere. The data files are imported to Skybox View using an import task.

204 Collection: Obtain the data directly from the device or the device management system. You create a task in Skybox View, which instructs the Skybox View Collector to retrieve the necessary data from the device. This data is then added to the model. The primary reasons for selecting one strategy over the other are the presence of a data repository, device accessibility, and the rate of changes to the device. Import is usually used when: You have a repository. If your organization has a repository that contains the necessary data for specific devices, you can import data from the repository into Skybox View. A device cannot be accessed easily by a Skybox View Collector. Note: If the device is in a segmented network, the alternative is to install an additional Skybox View Collector in that network segment. You do not have the necessary access permissions to a device for retrieving the configuration and routing data. A device is managed by a team that does not allow you continuous access to the device. Devices managed by third-party vendors are typically harder to access. A device is updated infrequently, such as once a year. For infrequently updated devices, you could get an alert (reminder) and then import the data manually, rather than including them in the automatic collection. Collection is usually used when: A device is easily accessible and the configuration and routing information is not stored in a central repository. A device is frequently updated. Usually, you can schedule automatic collection of data from such devices to synchronize with device updates. If data from frequently updated devices is imported rather than collected (for any of the reasons mentioned previously), the import task should likewise be synchronized with the device updates. Modeling unsupported devices You can model devices that are not directly supported by Skybox View in the following ways: Create a script to translate the device configuration to Skybox View s Integration XML (ixml) and import the device data. For information about ixml, see the Integration part of the Skybox View Developer s Toolkit. Model the device manually in Skybox View. This is the simplest method to use if you have only a few devices that are not directly supported. Preparing scanning information Scanning information is necessary to build the model. It provides information about assets and services, and information about the vulnerability occurrences that exist on scanned assets. Scanning is not performed by Skybox View, but rather by external sources. Skybox View scanner tasks add scan data to the model. For a list of scanners supported by Skybox View, see The following types of scanning decisions in your organization affect Skybox View: Are the networks scanned regularly? How often?

205 Using which scanners? What level of scanning is used? Who is in charge of running network scans? Plan the collection of scan data for Skybox View according to the answers to these questions. Important: Skybox View requires unrestricted scanning output (that is, output with a minimum of control devices (such as firewalls) blocking the route between the scanner and the scanned assets). Skybox View later analyzes permitted and blocked access. To achieve unrestricted scans, you might need to install additional scanning agents in your network. Note: You can use the Network scans worksheet (on page 207) to help with this phase. Preparing the data For each network device that is to be imported, ascertain which files Skybox View needs to model the device and make sure that these files are available. For example, for a Cisco router, Skybox View needs the output of the show running-config and show ip route vrf * commands, stored in separate files. For detailed information, see Data formats for import tasks, in the Skybox View Reference Guide. Devices whose data is actively collected may require advanced preparation. For example, to collect configuration from Check Point firewalls, an OPSEC CPMI application needs to be configured on the firewall management module. For detailed information, see the Tasks section of the Skybox View Reference Guide, in the section about the relevant device. You can model devices that are not directly supported by Skybox View using Skybox View s Integration XML (ixml). For information about ixml, see the Integration part of the Skybox View Developer s Toolkit. Phases of deployment When deploying Skybox View in a large organization, it is useful to divide the project into phases and to define clear milestones for each phase in any of the following dimensions: Organizational Complete deployment for one business unit or division and then continue to the next one. Geographical Complete deployment for a specific site or location and then continue to the next one. These dimensions are not mutually exclusive and they can sometimes be used in parallel. First phase However you divide the network, it is recommended that you start the deployment with a first phase of a relatively small number of nodes (approximately 100 to 1000). Select a complete network environment of approximately this size and import the entire environment. The following is a basic workflow for the entire first phase when working with Exposure: 1 Add network information. Collect the network information for this phase offline, using Skybox View import tasks (Import Directory (for supported devices) and Import Basic are the simplest). Before you run these tasks, make sure that the necessary data for each device is stored in the correct location.

206 For information about importing the network environment, see Building the network topology (on page 51). For the complete workflow of importing a single device, see Workflow for importing a single device (on page 51). For information about preparing the data for each device, see the relevant subsection in the Tasks section of the Skybox View Reference Guide. 2 Add security information (on page 17). The model needs to include asset and vulnerability occurrence information to analyze risk and attacks. 3 Validate the model (on page 68). After the network and security information of the defined scope is included in the model, it must be checked for correctness. 4 Set up the Business Unit hierarchy (on page 23). The first phase of adding business information should include three to five top Business Asset Groups. 5 Add Threat Origins (on page 74). The first phase should include one or two major threats (the internet is already included as a threat): it is recommended that you start with external threats rather than threats that are inside your organization and define first the threats that pose the greatest risk to your organization. 6 Simulate attacks (on page 86) (which also provides exposure information). 7 Identify critical issues (on page 87). 8 Mitigate critical risks (on page 93). When you finish this phase, you will have a better idea how Skybox View works with your network and how to use it to lower risk in your organization. At this point, you can plan the scope of additional phases of deployment and prepare Skybox View to work in a more automated manner. Worksheets for planning deployment You can use the following worksheets to plan the deployment. To help you to keep track of changes, it is recommended that you keep track of the date on which each one was last updated. Deployment overview worksheet You can use the following tables to record overview information relating to the deployment. Architectural design Component Skybox View Servers Skybox View Managers Skybox View Collectors Servers Personal Nodes Quantity

207 Security Model Technical Data Product type # Platforms Sources of configuration data Routers / L3 Switches Firewalls Load Balancers / Proxies Vulnerability scanners* Network Mgmt. System Locations Comments Note: Vulnerability scanner information is only necessary when working with Skybox Risk Control. Contact information Contact Customer name and address Deployment contact person Phone #s Comments Main Secondary Device mapping worksheet You can use the following worksheet as a checklist for devices mapped into the model. Device Type Vendor Done? Version Device IP # Collection Method File Name / User & pwd Comments

208 Network scans worksheet You can use the following table to collect information about network scans in your organization. Scanner Scanner IP # Scanning Collection Policy File Name / Comments vendor version scope method name User & pwd Business Asset Group mapping worksheet You can use the following table to collect information about Business Asset Groups in your organization. Business Asset Group name Function/ usage # of asset s CIA severity Dependencies Owner Comments

209 Business Asset Group name Function/ usage # of asset s CIA severity Dependencies Owner Comments

210 Index A About attack simulation 151 About risk 152 About security metrics in Skybox View 13 About Skybox Risk Control 9 About the Skybox View Vulnerability Dictionary 11 Access Analyzer 163 Access Analyzer output 169 Adding additional connections 57 Adding Business Asset Groups 80 Adding custom IPS rules 192 Adding dependency rules 84 Adding location hints to the definition file 140 Adding new vendor-defined IPS rules 191 Adding organizational hierarchy (Business Units) 23 Adding supported devices 184 Adding Threat Origins 74 Additional customization 40 Additional destination options 167 Additional information about exposure 151 Additional security metrics parameters 180 Additional ways to model IPS devices 194 Adjusting the security metrics parameters 176 Advanced dependency rules 149 Advanced modeling scenarios 130 Analyzing security metrics 29 Assigning tickets to different owners 108 Attaching Perimeter Clouds to the network 55 Attack simulation and visualization 47 Attack simulation for continuous usage 103 Attack simulation from clouds 152 Automated IT security modeling 46 Automatic modeling 131 Automating collection 124 Automating tickets 104 B Basic architecture 11 Building the model 17, 51 Building the network topology 51 Business Asset Group mapping worksheet 208 Business Asset Groups 26 Business impact analysis and risk metrics 48 Business Impacts and Regulations 82 Business Units 24 C Calculation of scores for Remediation Latency Indicator security metrics 177 Calculation of scores for Vulnerability Level Indicator security metrics 176 Changing the security metrics scale 36 Changing ticket statuses 108 Check whether the problem is access-related 92 Checking for new entities 104 Closing tickets 109 Closing vulnerability occurrence tickets 109 Clouds 53 Clusters 142 Configuring the L2 network interfaces 137 Configuring the network interfaces of L2 devices 185 Connecting Clouds 56 Connecting VPN gateways to the tunnel network 133 Continuous risk management 103 Continuous usage 42 Creating access rules for the VPN 133 Creating an analysis 158 Creating and editing Perimeter Clouds 54 Creating and saving dedicated maps 61 Creating Connecting Clouds 57 Creating L2 devices 135 Creating Map Groups 65 Creating network segments 135 Creating new queries 163 Creating sets of tickets for multiple vulnerability occurrences 100 Creating task sequences 112 Creating ticket rules 105 Creating tickets 98 Creating tickets for a single vulnerability occurrence 96 Creating tickets manually 94 Creating VPN tunnels 131 Creating VPN units 132 Creating vulnerability definition tickets 99 Creating vulnerability occurrence tickets in the Attack Explorer 97 Customizing the security metrics 36 CVE compliance 183 D Data used for attack simulation 151 Defining a Business Asset Group 80 Defining Business Units 24 Skybox Risk Control version

211 Index Defining human Threat Origins 76 Defining IPS devices using ixml 196 Defining IPS devices using the GUI 194 Defining the collection strategy 203 Defining the scope 164 Defining the services 166 Defining the SLA per severity level 37 Defining the source and the destination 164 Defining Threat Origins 76 Defining unique locations for overlapping networks 139 Defining worm Threat Origins 78 Deployment overview worksheet 206 Deployment plan 201 Deployment team 202 Device mapping worksheet 207 Disabling and enabling Threat Origins 79 Discovery Center 23 Display filters 169 Display of risk values 155 E Explicit dependency rules 84, 150 Exporting data to CSV files 122 Exporting vulnerability occurrence data to Qualys format 123 F False positive reduction 125 First phase 205 FISMA/NIST and Risk Assessment reports 119 Fixing the topology 72 Focusing on a specific security metric 30 G General maintenance 127 Generating tickets from ticket rules 106 Guidelines for setting up scanner tasks 22 H How risk is defined for each type of entity 153 How this manual is organized 7 I Identifying entities in the base model 146 Identifying the critical issues 87 Impact levels 179 Implicit dependencies 85, 149 Importing overlapping networks 138 Inaccessible entities 173 Information requirements 202 Initial customization 36 Intended audience 7 Introduction to exposure 45 IPS dictionary 184 IPS support in Skybox View 184 Issuing alerts without tickets 106 L Limiting the scope of vulnerabilities reports 121 Locations 58 M Managing Business Units 25 Managing Threat Origin Categories 75 Managing tickets analyses 110 Manual modeling 131 Map Group hierarchies 66 Map Groups 65 Marking vulnerability occurrences 98 Marking vulnerability occurrences as ignored 93 Merging assets 147 Merging data 144 Merging entities 146 Merging link networks when each part is in a separate location 148 Merging networks 148 Merging overlapping networks 139 Mitigating critical vulnerability occurrences 94 Model completion and validation 69 Model integrity 127 Model maintenance 110, 124 Modeling L2 networks 133 Modeling multi-homed assets 143 Modeling unsupported devices 204 Modeling VPNs 130 Monitoring task results 116 Monitoring the risk status 103 Monitoring tickets 107 N Navigating the Network Map 63 Network scans worksheet 207 Network visualization (maps) 61 Normalizing the network information 145 O Obtaining asset and vulnerability occurrence data 18 Optimization 199 Optimizing Access Analyzer analysis 200 Other ways of adding organizational hierarchy information 27 Output of attack simulation 151 Overlapping networks 138 Overview of continuous usage 103 Overview of Skybox Risk Control 9 Overview of the Exposure feature 45 Overview of the Security Metrics feature 13 Overview of validating the model 68 Skybox Risk Control version

212 Skybox Risk Control User s Guide P Part I Security Metrics 12 Part II Exposure 44 Part III Continuous usage 111 Part IV Advanced topics 129 Part V - Planning deployment 201 PCI DSS reports 119 PCI DSS support in Skybox Risk Control 161 Performance considerations 199 Phases of deployment 205 Planning deployment 201 Predefined risk analyses 157 Predefined security metrics 14 Predefined vulnerabilities report definitions 122 Preface 7 Preparing a list of network devices 203 Preparing data for Skybox View 202 Preparing scanning information 204 Preparing the data 205 R Recalculating the security metrics 43 Regulation compliance 49 Related documentation 7 Remediation 41, 93 Remediation workflow 41 Removing outdated entities 126 Reports 118 Results tree 170 Retrieving the data 19 Reviewing attacks 90 Reviewing the Business Asset Groups 90 Reviewing the directly exposed vulnerability occurrences 88 Reviewing the Threat Origins 89 Risk analyses 157 Risk exposure management workflow 49 Risk factors 161 Risk formula 152 Risk profiles 160 Risks reports 119 S Saving the model 128 Saving the results 174 Scheduling tasks and task sequences 115 Searching for tickets 107 Security Metric properties 37 Security metrics notifications 42 Security Metrics reports 118 Segmenting networks 135 Setting up security metrics notifications 42 Setting up ticket automation 104 Simulating attacks 86 Simulating the effects of IPS devices 194 Skybox View analyses 156 Skybox View platform 9 Superseding Microsoft Bulletins 33 Supported data sources 203 Switching between security metrics 32 Skybox Risk Control version T Task groups 116 Task sequences 112 Technical support 8 Terminology for working with IPS devices 187 Testing connectivity 72 Testing enhanced coverage of an IPS device 197 Testing new IPS devices 197 Testing the effects of an IPS device using Skybox View 197 The process 10 Threat Origin Categories 75 Threat Origin types 74 Ticket rule alerts 105 Ticket rules 104 Tickets and workflow 106 Tickets reports 120 Troubleshooting multi-homed assets 143 U Understanding security metrics information 32 Understanding Skybox View risk 86 Understanding the results 170 Updating the dictionary 17 Updating the model 124 Updating the model after fixing vulnerability occurrences 101 Updating your dictionary 127 Using clouds as Threat Origins 149 Using model validation analyses 70 Using tasks for automation 112 Using the Do Not Outdate option 126 Using the low-level approach 34 Using the top-down approach 34 Using the What If model to test changes 101 V Validating IPS devices in the model 187 Validating the access rules RC 188 Validating the IPS rules 188 Validating the model 68 Validating the model when working on a continuous basis 127 Validating the setup for attack simulation 73 Verifying access 72 Verifying completeness 69 Verifying external connections 71 Verifying the effects of the IPS device 188

213 Index Verifying the topology of the model 70 Verifying topology 70 Viewing and editing task sequences 114 Viewing and managing IPS devices in Skybox View 189 Viewing risk 160 Viewing security metrics information 30 Viewing the access route 171 Viewing the Access Route in text format 172 Viewing tickets 107 Virtual firewalls 142 Virtual routers 141 Vulnerabilities reports 121 Vulnerability detection 19 Vulnerability Dictionary 181 Vulnerability Dictionary information 181 Vulnerability Management reports 120 Vulnerability occurrence life cycle 124 Vulnerability occurrence maintenance 124 Vulnerability occurrences in the model 22 W What happens during ticket generation 106 Workflow 87 Workflow for importing a Cisco IOS router 51 Workflow for importing a Qualys vulnerability scan 20 Workflow for security metrics 16 Working with IPS in Skybox View 184 Working with Map Groups 66 Working with tickets 107 Worksheets for planning deployment 206 Skybox Risk Control version