risc networks operations security guide - cisco.com · RISC Networks Operations and Security Guide Page 3 of 3 INTRODUCTION This document is designed to give an overview of the different

RISC Networks, LLC Contact 1-866-808-1227 / [email protected] / www.riscnetworks.com

RISC Networks Business Technology Analytics

Operations and Security Guide

Version 2.503.22.2011

RISC Networks Operations and Security Guide Page 2 of 2

Table of Contents

INTRODUCTION 3

RISC ARCHITECTURE 3

Global Data Center Architecture 3

Command & Control 4

Data Handling & Security 5

Data Confidentiality & Compliance 6

ANALYTICS ENGAGEMENT PROCESS 7

Discovery Phase 7

Inventory Phase 8

Performance Phase 9

RN100 & RN50 SECURITY 9

Advanced Embedded Operating System 9

Stateless System Resets 10

Encrypted Credentials 10

Data Handling 10

SPECIFIC ANALYTICS ENGAGEMENT OPERATION & SECURITY 10

Service Level Analytics (Voice & Video Readiness) 10

Cisco Unifieed Communicationa 11

Traffic Analytics 12

Data Center Analytics 12

Cisco Discovery Services 13


INTRODUCTION

This document is designed to give an overview of the different stages, protocols, methodologies andsecurity aspects of performing a RISC Networks Business Technology Analytics engagement. RISCNetworks’ Analytics engagements are designed to deliver high impact results with minimal effort on thepart of the customer and/or partner. RISC Networks engagements run in several distinct stages andcover multiple technologies using our exclusive RN100 and RN50 Secure Appliances. In the followingsections, you will find explanations of the overall service delivery architecture, the various stages ofrunning an engagement, and the specific security aspects of each engagement process.

In order to deliver world class service to a worldwide customer base, RISC Networks operates a globallyscalable architecture that provides flexibility, elasticity, redundancy, and security for its customers. Thetwo major technical components of any RISC Networks service engagement are the collection of raw datafrom a customer’s environment and the processing and analysis of that data by RISC Networks’ UCEL(Unified Correlation Engine Logic). In order to facilitate these two components, RISC Networks hasdeveloped appliances, global data center architectures, and methodology that secures data, processes itquickly, and puts the results in the customer’s hands so they can take immediate action to resolve issues.

This document details and outlines the operational and security aspects of each of the components listedabove. As operational and/or security procedures change this document will be updated. Always get thelatest version from https://www.riscnetworks.com/resources/OpsAndSecurity.cfm.

RISC ARCHITECTURE

GLOBAL DATA CENTER ARCHITECTURE:


RISC Networks operates 3 Data Centers worldwide to provide services to its customers. RISC NetworksData Centers are located in the United States, Ireland, and Singapore. The United States data centerserves North and South America. The Ireland Data Center serves the EU and Africa. The SingaporeData Center serves RISC Networks Asian and Australian operations. Every engagement is run out ofone data center, they are never split and communication between Data Centers is restricted to commandand control synchronization and engagement communication as noted below. This provides significantsecurity for data residing within a particular Data Center, such as EU data within the EU data center.

The Data Center selected to run an engagement is based upon the country selected when scheduling theengagement. If a customer has a specific desire to have all raw data held in a particular region, forexample a global manufacturing firm that has a mix of NA, APAC, and EU operations may elect to keepall data within the NA or EU regions. The choice of Data Center is made when the engagement countryis selected. The RISC Networks platform identifies the Data Center (NA,EU,APAC) that will be usedwhen a customer schedules their engagement.

RISC Networks Data Centers provide 24/7 physical access control. All visitors to the Data Centers arecontinuously escorted while on site. The actual physical location of the Data Center is not disclosed forsecurity reasons. The Data Centers themselves are some of the most advanced in the world.

COMMAND AND CONTROL:

Communication from the RN100 and RN50 appliances to any RISC Networks Data Center is performedusing 256-bit SSL encryption. The command and control interface that exists allows RISC Networksservice delivery technicians to instruct each remote appliance with a set of predefined commands. Thecommand and control interface is not remote access to the appliance, but rather a controlled, monitored,and logged interface that enables RISC Networks to deliver the more comprehensive analyticsengagements possible anywhere in the world.

RISC Networks does not support engagements that utilize web filtering or proxy servers. The RN100appliance requires “proxy-free” access to the Internet via SSL (TCP port 443). If needed, the customermay limit RISC Networks access to the following IP addresses, which are assigned to our websites in ourglobal data centers:

US / North and South America – 50.16.203.81 (www.riscnetworks.com) US / North and South America – 50.17.235.104 (app1.riscnetworks.com) Ireland / EU and Africa – 79.125.13.50 (eu.riscnetworks.com) Singapore / APAC – 122.248.255.196

If requested by the customer, a RISC Networks Service Delivery Manager, who will be identified to thecustomer as such, can provide remote diagnostic support for RISC Networks appliances. This access isonly performed at the request of the client. No service delivery personnel, other than senior managers,have the ability to perform these diagnostics and they are only performed at the request of the customer.

ANALYTICS LOG UPDATES AND COMMUNICATIONS

Communication is critical for a successful engagement. RISC Networks provides a secure online portalfor customers and partners to communicate. All communication input into the portal is archived in the NA


Data Center in the United States. For this reason, no personal data should be put into the log as thatdata will leave the respective theatre. In addition, a copy of all communication input into the log isemailed to all associated parties. For this reason, information that is sensitive should not be placed intothe log file. Credentials such as SNMP Strings, Windows Passwords or CUCM and VMware loginsshould only be placed in the bootstrap utility and physically inserted into the appliance.

If customers choose to use SNMP Write access, they can input the SNMP Write strings into the RISCNetworks secure portal for both Service Level Analytics and any time that the string needs to becommunicated through the Manage Assessment page. SNMP Write strings are only held transiently andare immediately pushed to the RN100 appliance. They are not stored in the database in the NA DataCenter for more than 1 minute and are never emailed.

If RISC Networks personnel review Analytics data, whether as part of an engagement or at the request ofa customer or partner, this data must necessarily travel to the United States. This review is optional,although not typically an additional expense. By default, for engagements run outside of the UnitedStates, the only data that is reviewed is the Visio diagram of the network. The generation of the Visiodiagram is based on Comma Separated Values (CSV) files that must be manually compiled into aworking Visio diagram for display to the customer. These files do not contain any personal data.

DATA HANDLING AND SECURITY:

All data is uploaded from RN100 and RN50 appliances to the RISC Networks NAC using 256-bit SSLencryption. Before being uploaded the raw data is encrypted using a 2048-bit symmetrical public key.This key is rotated every 30 days. The data is uploaded on demand only and is scheduled to occurovernight in each respective region. Data upload sizes vary based on the size of the engagement.Average data upload sizes for 1 week engagements are approximately 40MB per upload. These uploadsoccur only 1 time per day.

Sensitive credentials, such as windowspasswords, SNMP strings, VMware logininformation, Cisco CallManagercredentials or any other securecredential entered into the applianceduring the bootstrap process are neveruploaded. These credentials are kept ina separate location on the RISCappliance and are used by the localprocesses on the appliance. RISCNetworks delivery engineers never knowor have access to the credentials usedto bootstrap the appliance.

Once the secure, encrypted data uploadis complete, the encrypted raw data isstored in a secure repository that is notdirectly accessible from the Internet.RISC Networks provides full auditing for


every access of this data as part of its final reports. Customers may request a complete audit trail ofanyone who accesses their raw data, their final reports for download, and deletion of raw data and finalreports.

The encrypted raw data is accessed by RISC Networks’ UCEL reporting engines and is decrypted, storedin transient database instances and accessed for report generation. Final reports are placed into storageand accessible only through RISC Networks secure web portal for download by customers and partners.

Raw customer data is held in RISC Networks’ NAC for a period of 10 days after the engagement hasended. After 10 days, the data are deleted and the storage device that data was stored on returns to thepool of data storage available for other RISC Networks’ engagements. When a storage device hasreached the end of its useful life, procedures include a decommissioning process that is designed toensure customer data are not exposed to unauthorized individuals. RISC Networks uses the techniquesdetailed in DoD 5220.22-M (“National Industrial Security Program Operating Manual “) or NIST 800-88(“Guidelines for Media Sanitization”) to destroy data as part of the decommissioning process. If ahardware device is unable to be decommissioned using these procedures the device will be degaussedor physically destroyed in accordance with industry-standard practices

DATA CONFIDENTIALITY AND COMPLIANCE:

Privacy and security of Customer’s information, including personal data, are a primary concern for RISCNetworks. RISC Networks’ data centers adhere to strict regulatory compliance standards such as:

PCI DSS Level 1, SAS 70, and ISO 27001

At the end of any engagement, RISC Networks anonymizes data for aggregation reporting and thendestroys any customer specific data. RISC Networks does not collect personal user data such as:

User logins or passwords Data Files (office documents, text files, etc) Email Files Database Files Any files containing user information Application payload information

Data collected within a specific geographic region, for example the European Union (EU), never leavesthat geographic region. Our global data centers reside in the United States, Ireland, and Singapore.Data from our APAC operations remains in Singapore and data from EU engagements remains in the EU.

To the extent that any particular engagement requires the processing of personal data in the EU and theirsubsequent transfer outside of the EU, RISC Networks, will, as a data processor, upon request, enter intothe EU Standard Contractual Clauses for the transfer of personal data to third countries. In addition,RISC Networks is classified as a “Data Processor” under EU privacy laws and shall act only oninstructions from its Customer and will have adequate technical and organizational security measures inrelation to the processing of any personal data.


DATA ANONYMIZATION AND AGGREGATION:

In order to continually improve the RISC Networks experience for customers around the world, RISCNetworks will anonymize customer inventory and performance data and aggregate them in a datawarehouse at the completion of every engagement. This data warehouse is then used to build modelsthat provide valuable insight for customers as they attempt to determine their relative performance fromthe overall IT population.

RISC Networks archived data consists of inventory information (without IP addresses, serial numbers, orhostnames), and performance metrics. Any identifiable characteristics are stripped and onlyperformance metrics and or anonymous asset information is kept.

Customers can request that their data not be aggregated by emailing [email protected] within10 days of the completion of the engagement. These requests will be positively acknowledged but mustbe made after the engagement has completed.

ANALYTICS ENGAGEMENT PROCESS

DISCOVERY PHASE:

Process:The RN100 performs network discovery using standard network mapping software. The RN100 probeinterface will only scan the subnets that are provided to RISC Networks by the Customer and/or Partnerin order to determine what devices in the network are available to participate in the Analyticsengagement. This stage of the Analytics engagement is designed to introduce minimal amounts of trafficonto the network. A class B subnet typically takes about 2.5 hours to scan.

Protocols:The RN100 utilizes the following protocols to discover the existence of network devices during thediscovery phase of the Analytics engagement:

ICMP echo UDP echo (port 161) TCP Connect (ports 135, 80, 8443)

57% of Networks atleast 1 server w/ errors

Which of your servers are failing and why?Are you one of the 57% with back up failures?Find out before it’s too late.

Data based on 3467 Servers from 117assessments

Data Resource Sample: Statistics show you are likely having back-up failures right now. Why?

1 Network had 30% ofservers with failures

13% of Servers arehaving back-up failures

57% haveat least 1w/errors

30% hadBack-upFailures

13% haveBack-upFailures


Security:As part of the Discovery Phase the RN100 will test SNMP credentials on all devices that meet eligibilityrequirements for access on UDP port 161. This will utilize SNMP v1, SNMPv2, or SNMPv3 to query thedevices using the SNMP strings or credentials entered while bootstrapping the RN100 Appliance. RISCNetworks does NOT perform OS Fingerprinting or aggressive port scanning techniques to determine allopen ports on machines within the network. Port scans are limited to the TCP and UDP ports listed in the“Protocols” section above. In addition, RISC Networks does NOT “spider” the IP network. Scans arelimited to the subnets requested by the Customer and/or Partner and are not based on routing table orneighbor information unless requested by the Customer.

INVENTORY PHASE:

Process:The Inventory Phase starts with detailed SNMP inventory collection on all devices that were accessedsuccessfully with an SNMP strings during Discovery. This includes routers, switches, firewalls, Linux/Unixservers, etc. The amount and type of information collected is dependent on the device type andmanufacturer. After all SNMP capable devices are fully inventoried, Windows Inventory begins bytesting Windows Management Instrumentation (WMI) authentication on all devices meeting eligibilityrequirements. All Windows workstations and servers that are accessible via WMI are then inventoried aswell as having their network connections documented. If the Analytics engagement is a Cisco UnifiedCommunications Analytics engagement, CallManager information is pulled at this time. This informationincludes phone, dial plan, and service information as part of the inventory. Finally, if the engagement is aData Center Analytics engagement, inventory information is pulled from ESX or vCenter servers via theVMware vSphere API. At the conclusion of the Inventory phase, all data is exported, encrypted, anduploaded via a secure SSL connection to RISC Networks’ NAC for inventory analysis and reportgeneration.

Protocols:SNMP v1 and V2 are utilized to query information on all SNMP capable devices. WMI is utilized toaccess all Microsoft Windows servers and workstations for inventory purposes. Cisco CallManagerinformation is obtained using the Cisco Systems AXL interface. AXL is an XML based web service thatallows secure access to CallManager configuration and performance information. VMware information isaccessed using the VMware vSphere API.The following URLs and ports are accessed on equipment at the customer site and must be accessible inorder to perform the engagement.

SNMP – UDP port 161 WMI – TCP port 135 and other dynamic ports as per Microsoft implementation AXL

o CallManager 5.X (and later) – https://x.x.x.x:8443/axl https://x.x.x.x:8443/perfmonservice/services/PerfmonPort

o CallManager 4.X – http(s)://x.x.x.x/soap/astsvc.dll http(s)://x.x.x.x/CCMApi/AXL/V1/soapisapi.dll


Security:Inventory data includes information regarding OS levels, hardware configuration, installed applications,Microsoft Office and Windows product keys, serial numbers, Windows Event Viewer logs, networkconnections, topology information, and Layer 2/Layer 3 network information. This information is used inorder to verify best practices are being met and that devices are properly upgraded to their requiredlevels. In addition, it is used to create a network topology map that outlines the current state of thenetwork so that the Customer and/or Partner can work from a current, real-time picture of the network.The following types of information are NEVER collected by RISC Networks:

o User logins or passwordso Data Fileso Email Fileso Database Fileso Any files containing user informationo Actual application traffic

PERFORMANCE PHASE:

Process:Once the initial inventory has been confirmed, performance collection occurs on all SNMP accessiblenetwork infrastructure devices as well as all Windows servers accessible via WMI. Performance statisticsare accessed at an interval of no greater than 1 sampling every 5 minute interval. At the end of theperformance phase, all data is uploaded to RISC Networks’ NAC for processing.

Protocols:SNMP, WMI, AXL, and SOAP are used to collect performance information.

Security:There is no additional security information that differs from the inventory phase of the Analyticsengagement during the performance phase.

RN100 AND RN50 SECURITY

ADVANCED EMBEDDED OPERATING SYSTEM:

The RN100 and RN50 appliances run an advanced proprietary embedded operatingsystem. This system was developed based on the widely adopted 2.6 Linux Kernel.

RN100 APPLIANCE RN50 APPLIANCE


No access to the appliance is allowed with any protocol with the exception of a RISCmanagement session and those connections initiated by the RN100 or RN50 itself. SSHand ICMP are allowed but are used solely for connectivity testing and troubleshooting.

Technology built into RISC Networks’ system allows for a stateless operating system out ofa read-only file system on each boot.

STATELESS SYSTEM RESETS:

The RN100 and RN50 Secure Appliances are built to run off of a read-only operating system. Thistechnology allows the appliance to return to a factory default state after each reboot. Upon reboot allactive data is lost, insuring appliance security and integrity between Analytics engagements.

**The stateless feature adds additional importance to maintaining reliable power to the RN100 and RN50appliances throughout the Analytics engagement so as to not lose valuable Analytics engagement data.

ENCRYPTED CREDENTIALS:

Customer security and the proper handling of network credentials are of the utmost importance to RISCNetworks as well our partners and customers. To guarantee this security, RISC Networks hasimplemented the following features with regards to handling credentials:

Credentials are encrypted immediately upon being entered within the USB Bootstrapapplication.

Upon successful bootstrap of the RN100 the encrypted XML file is deleted from the USB. RN50 bootstrap files contain no credentials. All credentials transferred to the RN100 from the USB bootstrap are maintained within the

live memory state assuring they are deleted upon reboot of the appliance. Credentials are NEVER uploaded to RISC Networks’ NAC.

DATA HANDLING:

Appliance Data:All data and credentials contained within the RN100 and RN50 appliances are deleted once power isremoved from the unit. As an additional precaution the memory space used for data storage is thenoverwritten during the next boot up of the RN100 appliance to assure there is absolutely no way tocompromise any data contained within the appliance. The RN50 operating system and all associatedfiles run completely in Dynamic RAM.


SPECIFIC ANALYTICS ENGAGEMENTS OPERATIONS AND SECURITY

SERVICE LEVEL ANALYTICS (VOICE AND VIDEO READINESS):

RISC Networks Voice and Video Readiness Analytics engagements require either the use of Cisco’s IPService level Agreement (http://www.cisco.com/go/ipsla ) technology or deployment of RISC Networks’RN50 appliances to simulate and evaluate the performance of real time traffic on the network. In order todeploy the IPSLA configurations, SNMP write strings are required for each source and destination device.These write strings can either be provided securely through the USB bootstrap just as read-only stringsare or they may be provided through the secure web interface where they will be pushed out over SSL tothe appliance.

RISC Networks RN100 deploys the IPSLA configuration with the following attributes for added securityand ease of operation:

Configurations are deployed with a finite runtime ending shortly after the completion ofthe Analytics engagement so they will automatically be destroyed at the completion of theAnalytics engagement.

Configurations are not deployed as eligible for viewing within the running configuration ofthe IOS device. Typically IPSLA configurations would equate to potentially hundreds oflines within the CLI often making a running-configuration unmanageable.

Configurations are not eligible for saving within the NVRAM. This means it is importantIPSLA source and destination devices are not reloaded for any reason during the courseof the Analytics engagement.

Active IPSLA simulations can be terminated early by either reloading the IPSLA sourcedevice, by removing the operation via SNMP from the RN100 devices or by manuallyremoving the entry via the CLI on the source device.

RISC Networks deployed IPSLA operations are visible using the “show ip sla” commandin Cisco IOS.

All SNMP write strings are handled with the same security precautions as SNMP read-only strings. Inaddition SNMP write strings are only required for a short period of time to deploy the IPSLA configuration.Once fully deployed it would be acceptable to remove those write strings from the IPSLA source anddestination devices if the customer or partner choose to do so.

RN50 Appliances do not require SNMP Write strings for any devices. The RN50 appliance simulatestraffic between itself and other RN50 nodes on the network. Each RN50 appliance is controlled by theRN100, and they do not act independently. The RN50 appliance requires IP connectivity to the RN100appliance but does not require Internet access. The RN50 appliance will communicate to the RN100appliance and to other RN50 appliances on several ports as they coordinate clock timing (NTP), logging,and back-end database access for reporting statistics. RISC Networks requires that IP connectivity (TCPand UDP) be open for RN50 appliances to communicate to RN100 appliances.

For more information regarding Service Level Analytics see our data sheet athttps://www.riscnetworks.com/sla_description.cfm


CISCO UNIFIED COMMUNICATIONS:

The Cisco Unified Communications Analytics engagement requires a Unified Communications ManagerAXL username and password. Although this username and password combination can be a user withinthe ‘Super Users Group’ only ‘AXL API Access Group’ is required for CUCM 5.X and later. It isrecommended to setup a temporary AXL user where possible which then can be deleted at thecompletion of the Analytics engagement.

Cisco Unified Communications credentials entered with the USB bootstrap are encrypted and handled inthe same manner as Windows and SNMP credentials. All are maintained on the RN100 for the durationof the Analytics engagement and deleted with any reboot of the appliance.

TRAFFIC ANALYTICS:

RISC Networks’ Traffic Analytics module is used to capture actual network traffic and report on trafficprofiles within the network. The two methods of deploying traffic analytics, embedded and RN50 based.

Embedded Traffic Analytics involves the deployment of Cisco NetFlow within a Cisco environment. Thisdeployment is done via SNMP Write strings which are required in order to deploy embedded TrafficAnalytics. RISC Networks does not support user deployed NetFlow configurations. Cisco NetFlowtechnology provides accounting records only for traffic. No user traffic is captured. Only a record of thetraffic (source and destination IP, source and destination port, protocol, bytes, duration, etc) is available.

RN50 appliances capture traffic through a span port on a switch. The RN50 appliance does not recordany user payload information for use in its analysis. Deep packet analysis that is required is done on theRN50 appliance itself as part of a protocol decoder and is used only for statistical analysis. For examplean HTTP GET followed by an HTTP 200 OK message would represent the duration of a web sitedownload. This level of analysis may be performed by the RN50 but the details of the web page itself,including user input data or return data, are not reported to the RN100 for processing. The raw capturesof the details are overwritten every 5 minutes on the RN50 and are permanently lost after power cycling.

For more information on our Traffic Analysis module, see our data sheet at:https://www.riscnetworks.com/ta_description.cfm

DATA CENTER ANALYTICS:

Data Center Analytics adds VMware inventory and performance data as well as Fibre Channel inventoryand performance data as additional data sets. For VMware, RISC Networks utilizes the VMwarepublished vSphere API in order to collect information from vCenter and individual ESX servers. For ESXservers, the root password is normally required to access the vSphere API.Access to the vSphere API can be tested by pointing a web browser to: https://x.x.x.x/mob


This URL will return a login prompt that will verify the credentials required to access the vSphere API.RISC Networks does NOT use root credentials to log onto ESX or vCenter servers. The API is the onlyaccess that RISC Networks has to the VMware environment.

SNMP is used to collect information from Fibre Channel switches. RISC Networks does NOT directlyaccess the Fibre Channel network via taps or any other sniffing tools. SNMP read-only access to FibreChannel infrastructure is required for RISC Networks to collect information.

CISCO DISCOVERY SERVICES:

RISC Networks utilizes Cisco Discovery Services (CDS) in order to obtain more specific informationregarding Cisco infrastructure at a customer site. RISC Networks , Cisco and Cisco partners respect thatcustomers are concerned about their privacy and network security and may be apprehensive aboutallowing an engineer to use a network assessment tool to discover data from their network andsubsequently upload the data to Cisco using Cisco Discovery Service (CDS) for data analysis.

Cisco and RISC Networks have implemented several mechanisms to ensure customer data security. Inaddition, you will be required to accept an “Authorization to Proceed” (ATP) agreement before RISCNetworks will upload data to Cisco CDS. An ATP helps ensure protection of customer data andspecifically prohibits the dissemination of such data, providing assurance that neither Cisco nor RISCNetworks will share or divulge customer data. Customers should be advised that data will be used onlyfor the purpose of network analysis.

Once inventory data is collected by RISC Networks, if requested by the customer, it will be uploaded toCisco Systems’ CDS application at the following URL: https://wsgx.cisco.com.

Transferring the Data – If utilizing CDS for analysis, customer network data is transferred from RISCNetworks’ RN100 to Cisco using a secure HTTPS protocol to an internal Cisco CDS web service gatewaywhere it is processed to provide detailed EoX, PSIRT, field notice and service coverage analysis.

Before transferring data to Cisco for analysis, passwords and security credentials are stripped from thedata. RISC Networks does not collect running configurations at this time, and SNMP data does notcontain passwords or other sensitive configuration information. Instead of using IP addresses or hostnames to identify a device, a generic Device ID will be assigned. After processing, the analyzed data istransferred back to RISC Networks RN100 onsite at the customer using the same secure HTTPSprotocols. It is then uploaded to the RISC Networks’ NAC as part of normal data upload procedures andused to generate the network analytics reports.

Storing the Data – The raw discovery data and analyzed XML report data are stored in a secure Ciscodatabase behind Cisco’s firewall. The data is accessible only to CDS administrators for troubleshootingpurposes. Other Cisco personnel may have limited access to high level transaction reporting that doesnot include customer inventory details.

All data is stored and eventually archived unless purging is specifically requested by the customer. Thecustomer’s data is only accessible by Cisco or the partner who initiated the engagement.


Data for “Know the Network” (KTN), or service coverage reports, if requested, is also securely stored inCisco databases behind the firewall. KTN reports are available only to the engineer who initiated theengagement and the Cisco service account team.

Purging Customer Data from Cisco Databases – The data obtained in the discovery process anduploaded to Cisco for processing can be deleted from Cisco’s database if requested by the Customer.

If service coverage reports were requested, the KTN data and reports need to be purged separately fromthe KTN portal (http://tools.cisco.com/ktn/). KTN data can be deleted from the report view.

Partner-Specific Security Issues – Discovery information will not be sold or distributed to anyoneoutside of Cisco, or used for direct marketing purposes.

Documents

risc networks operations security guide - cisco.com · RISC Networks Operations and Security Guide Page 3 of 3 INTRODUCTION This document is designed to give an overview of the different