Whitepaper
Building a Successful Security Operations Center This paper outlines industry best practices for building and maturing a security operations center (SOC). For those organizations planning to build a SOC or those organizations hoping to improve their existing SOC this paper will outline the typical mission parameters, parameters, the business case, people considerations considerations,, processes and procedures, as well as, the technology involved. Research 014-052809-09
ArcSiht, Inc. 5 Results Wa, Cupertino, CA 95014, USA www.arcsiht.com info@arcsiht.com
Corporate Headquarters: 1-888-415-ARST EMEA Headquarters: +44 870 351 6510 Asia Pac Headquarters: 852 2166 8302
Whitepaper: Building a Successful Security Operations Center
Intrdctin In order to prevent the mriad of modern attacks, compl with overnment and industr reulations, monitor deploed technolo solutions, and verif the endless human interactions with technolo, oranizations turn to industr-leadin securit technolo. The may go to IBM Internet Security Systems for their network intrusion prevention systems (IPS), Cisco for their rewall solutions, and McAfee for host-based protection. This heteroeneous approach to selectin securit solutions provides oranizations the best-ofbreed technoloies and offers inherent securit b not relin on an sinle vendor or securit platform. The combination of technoloies does, however, present a lare challene - there is no inherent wa to normalize, areate, and correlate the security events across technologies. Further, one team may support the rewalls, another may support the network IPS devices, and et another ma support the host-based securit tools. This leads to securit monitorin that is performed usin different tools and by different teams. Piecing together the details of an attack in r eal-time becomes incredibly difcult and even forensic analsis after an attack is slowed b the need to combine event streams. In realit, buildin and maintainin a stron securit posture necessitates a centralized effort to monitor, analze, and respond to securit events across technoloies as quickl as possible. To meet this need, man oranizations turn to Manaed Securit Services Providers (MSSPs) to outsource the bulk of securit monitoring and testing. MSSPs offer a number of benets because they can: •
Monitor securit events around-the-clock and provide in-depth information securit expertise.
•
Spot patterns across a number of customers to provide advanced warnin on new threats.
•
Provide services to customers that do not have dedicated information securit staff.
However, MSSPs also present a number of disadvantaes. Namel, MSSPs do not: •
Have an in-depth knowlede of the customer ’s policies, procedures, or overall IT environment.
•
Offer dedicated staff for ever customer. Onl lare oranizations that spend the most with the MSSP enerall receive dedicated support.
•
Offer customized services, processes, or procedures for the customer needs. MSSPs strive to standardize services in or der to ain economies of scale in providin securit services to man customers.
•
Store securit data onl at the customer premise. Securit data will be transmitted and stored at MSSP locations that ma or ma not be in the home countr.
Weihin the considerations, man IT roups decide to build their own Securit Operations Center (SOC) to correlate events and centralize the securit monitorin, analsis, and response within a sinle team. For these oranizations, the MSSP’s disadvantaes outweigh its benets. There are unique business requirements that require a dedicated SOC, or there may be cost drivers that dictate the need for an in-house SOC. Buildin an in-house SOC does, however, present its own set of challenes and man roups strule on how to best start. This paper will offer a clear understandin of how to build our own SOC and balance the triad of IT project components – people, processes, and technolo - to jumpstart our efforts.
Missin nd Bsinss Cs Prior to buildin a securit operations center, oranizations need to take some time to plan. All too often this plannin focuses onl on the people, process, and technolo components of the project and inores outlinin the fundamental drivers for wh the SOC is needed and what business problems the SOC will solve. Prior to developin the project plan for buildin a SOC, project sponsors need to take a hard look at the overall mission and business case for the SOC.
ArcSight 1
Whitepaper: Building a Successful Security Operations Center
Missin All successful teams need a unifin sense of purpose to help motivate team members, prioritize work, and respond effectivel to the changing needs of the business. Time spent in this phase of planning will benet the SOC long-term. Prior to building a SOC, oranizations must answer the followin questions: •
What needs will the SOC meet for the oranization?
•
What are the specic tasks assigned to the SOC? (e.g., detecting attacks from the Internet, monitoring PCI compliance, detecting insider abuse on the nancial systems, incident response and forensic analysis, vulnerability assessments, etc.)
•
Who are the consumers of the information collected and analzed b the SOC? What requirements do the hope to impose on the SOC?
•
Who is the ultimate project sponsor for the SOC? Who will “sell” the SOC to the rest of the oranization? What requirements will he or she lev on the SOC?
•
What tpes of securit events will eventuall be fed into the SOC for monitorin?
Bsinss Cs There are ver few or anizations that are oin to approve the build-out of a SOC without a clear outline of the costs and strateies to recover those costs. In outlinin the costs of the SOC, the followin items will help start the discussion: •
Facilities: Furniture, computer equipment, special badin requirements, power, HVAC, telephon
•
SOC Labor: Securit analsts, shift leads, SOC manaers
•
Supportin Labor: Network support, sstem support, database support, telephon support, securit device manaement (if not performed b the SOC)
•
Education and Trainin: Classes, conferences, continuin education
•
Threat intellience subscriptions: Up-to-the-minute information on the latest threats
•
Monitorin technolo: Hardware, software, storae, and implementation services
•
Additional technoloies: Problem and chane manaement, email, knowlede sharin
Recoverin these costs is a much touher problem to solve. The followin list outlines some common approaches in justifin the expense of a SOC: •
Cost avoidance: Buildin the SOC will cost far less than not detectin, preventin, and respondin to attacks.
•
Cost efciencies: Chances are that man of the SOC pr ocesses or technoloies can help automate functions alread takin place within the oranization. B acceptin a new data feed and producin automated reportin, a SOC can often save the oranization mone b reducin manual effort.
•
Cost sharin: In man cases, other roups are currentl tasked with the responsibilities outlined for the future SOC. Are those roups willin to “outsource” these responsibilities to the SOC? Havin other or anizations help to foot the bill can minimize the overall impact to all.
•
Revenue / Cost Recover: Can SOC services be offered to customers – either internal or external? There is more work in determinin separation of information amon customers, pricin models, and other business aspects, but actual revenue (or cost recover in the case of internal customers) is a powerful arument where SOC services can be leveraed to perform securit services for other oranizations.
ArcSight 2
Whitepaper: Building a Successful Security Operations Center
Pp Once the SOC mission and business case are clearl outlined, project teams can then focus on the traditional IT project components of people, process, and technolo. While no portion of the triad is more important than the other, oranizations tend to fail more often in attractin and retainin the ke people necessar to operate a SOC effectivel.
Sctin The most common error in implementin an internal SOC is attractin people with the riht skills. Companies tend to start with too low a skill set for the analst. The SOC analst is the infantr man of the information securit communit enaed in dail trench warfare with a touh and innovative opponent. This is an opponent who understands the riors of monitorin a console for malicious events that are masked b thousands of nuisance events. The effective SOC analst needs a ood deal of trouble-shootin patience, the ability to research problems, and an unappable ability to communicate during stressful times. It takes more than entry level IT skills to succeed. While the exceptional candidate can o from a help-desk technician to bein an effective SOC analst, a better initial capabilit is found in sstem administration, desktop support, and network operations personnel. Personnel experienced in network, server, and desktop support tend to have the troubleshootin backround to excel quickl in the tpical analst tasks involvin the depths of the TCP/IP protocol suite and various intrusion detection sinatures.
Crr Prgrssin Monitorin and respondin to an endless suppl of securit events is enouh to tire even the most eaer information securit professional. As such, the tpical tenure of a SOC analst is between one to three ears. This makes it imperative to continuall identif candidates for the next eneration of analsts and plan the career proression for existin analsts. The SOC Manaer should develop stron relationships with other IT roups to help identif those candidates wantin to start a new information securit career. Additionall, the SOC Manaer should look toward Incident Response teams, Audit, and other advanced information securit roups to help offer SOC personnel a career path after their SOC tenure.
Trining No SOC analst can be effective without appropriate trainin; luckil, there are ver ood options for buildin an effective trainin proram. When craftin trainin plans, SOC manaers should include both formal trainin on standard information securit skills and on-the-job trainin (OJT) to maximize the analsts’ effectiveness within the oranization. Formal trainin should include the SANS (Sstem Administration and Network Securit) “Intrusion Detection in Depth” trainin module and the GCIA (GIAC Certied Intrusion Analyst) certication. This is the industry standard in training analysts in the fundamentals of TCP/IP, TCP/IP monitorin tools, and skills associated with advanced intrusion analsis. For those oranizations standardizin their Security Information and Event Management (SIEM) program around ArcSight, the ArcSight Certied Security Analyst (ACSA) training is a must-have. ACSA trains analysts to properly identify, correlate, and lter critical security events using the ESM product. On-the-job training programs should provide an overview of important information security concepts, training on specic intrusion detection tools in use, analtical processes and procedures, and effective communication techniques. The SOC analst will be required to effectivel communicate and brief all levels of enineers and senior manaement durin times of extreme stress, thus trainin in manain combative communication is invaluable. This trainin should also include the hierarch of communication methods. Learnin when to pae, call, e-mail or assin a ticket is a critical skill. Additionall, it is important that an analst learn to communicate in concise well-written papers and e-mails. SOC manaers should create a proram that has aspirin analsts writin analtical papers and then presenting their ndings to their peers to hone written and verbal communication skills.
ArcSight 3
Whitepaper: Building a Successful Security Operations Center
Stffing Pns Stafng plans will evolve directly out of the needs of the mission. Is the SOC a virtual entity where events are collected, analyzed, alerted, and reported? Must the SOC have full-time personnel to monitor consoles, analze, alert, and report? Or, does the SOC need full stafng twenty-four hours a day, 7 days a week, all year r ound? These mission needs will dictate the stafng models that must be implemented. Despite the particulars of any giving stafng models, there are some guidelines to follow: •
One SOC analst should never be alone in mannin a shift. There are a mriad of safet and performance issues that can result.
•
Each shift and role within the SOC should have clearly-dened responsibilities and deliverables.
•
There should be no ambiuit in what is expected from each analst at an iven time durin a SOC shift.
•
There needs to be a clear “hand-off” between shifts. Each shift should keep a formal lo of events documentin those issues that need additional or continual attention.
•
There is a signicant issue that always shows up on any night shift - the analysts feel ignored and uninformed. The SOC manaer must work hard to ensure he/she constantl communicates with the niht shift and even schedules time to work alonside.
•
In order to staff a SOC 24x7x365, ten SOC Analysts are required. The shift schedule that best ts this stafng model is four twelve-hour shifts per week. Each analst works three das on, four das off, followed b four das on, and three das off. This totals to 84 hours in two weeks. Additionall, two of the more experienced analsts (commonl referred to as Level-2 Analsts) work an 8x5 shift and are available to cover shifts for planned and unplanned absences. Fiure 1 shows a sample schedule for a 24x7x365 shift schedule.
DaIly SCheDule (8aM To 8aM) Level 1 Analsts
Niht Shift
Da Shifts 1 & 2 10AM to 10PM
Niht Shifts 3 & 4 10PM to 10AM
Level 2 Analsts
Da Shift 8AM to 5PM
Niht Shift 5PM to 2AM
Securit Enineers
Da Shift 8AM to 5PM
On-call Rotation
SOC Manaement
Da Shift 8AM to 5PM
On-call Rotation
On-call Rotation
WeeKly SCheDule SUN
MON
TUES
WED
Level 1 Analsts (Week 1)
Shift 1 (Das) Shift 3 (Nihts)
Shift 4 (Nihts)
Level 1 Analsts (Week 2)
Shift 1 (Das)
Shift 2 (Das)
THURS
FRI
SAT
Shift 2 (Das)
Shift 3 (Nihts)
Shift 4 (Nihts)
Shift 3
Shift 3
Level 2 Analsts
On-call Rotation
Business Week
On-call Rotation
Securit Enineers
On-call Rotation
Business Week
On-call Rotation
SOC Manaement
On-call Rotation
Business Week
On-call Rotation
Fiure 1: Sample 24x7x365 SOC shift schedule
ArcSight 4
Whitepaper: Building a Successful Security Operations Center
Prcsss nd Prcdrs SOC processes and procedures can act as a buffer between the people and technolo. For example, new analsts will have ver little idea how to start and it’s likel that existin staff will not have a ood deal of dedicated time to help train. Well-documented processes and procedures can clearl uide the new analsts’ actions in those formative das. Additionall, the SOC technolo ma not have all the necessary features to accommodate a specic business need. Processes and procedures can pick up the slack by allowing people to follow uidelines to accomplish tasks manuall. To achieve an effectivel operatin SOC, the associated processes and procedures must not onl exist but also be mature. Maturit in process management is rst achieved by repeatability and then by continuous process improvement. The Carnegie Mellon ® Software Enineerin Institute (SEI) Capabilit Maturit Model ® Interation (CMMI) offers a reat approach to continuous pr ocess improvement. From the SEI web site: Capabilit Maturit Model ® Interation (CMMI) is a process improvement approach that provides oranizations with the essential elements of effective processes. It can be used to uide process improvement across a project, division, or an entire oranization. CMMI helps interate traditionall separate oranizational functions, set process improvement oals and priorities, provide uidance for qualit processes, and provide a point of reference for appraisin current processes. Because SOCs tpicall have a lare number of processes and procedures, CMMI offers a reat architecture to help oranize, maintain, and improve this body of work. For most or ganizations, CMMI Level 3 is a sufcient goal. This maturity level ensures the processes and procedures are documented and subjected to demonstrable improvement over time. In practical terms, this means that any given analyst on any shift will execute a procedure in exactly the same manner. Additionally, if an analyst nds an er ror or change needed in a procedure they can make an on-the-spot corr ection and all subsequent analysts will benet immediately from the improvement. Note: This tpe of dnamic process and procedure maintenance is best achieved b the use of a wiki collaboration environment (e.., Twiki or MediaWiki). A wiki documentation sstem is a collection of web paes that allows visitors to contribute and modify content on the y. While other knowledgebase tools can effectivel store documentation and offer adequate version control, not man tools can keep up with the dnamic needs of constant documentation updates like a wiki. (Note: A common use for dual monitors at SOC operations pods is to use one for console monitorin and the other for procedural reference and research.)
Subtle Event Detection Reporting Incident Management Intrusion Analysis ANALYTICAL
Prcss hirrc Generally speaking, a process denes who is responsible for doin which tasks, and a procedure tells them in detail how to accomplish the task. For a SOC, there ar e enerall fourteen main processes and around thirt-six subordinate procedures as shown in Fiure 2. These are arraed in a pramid to demonstrate that each process and accompanin procedures rel on the processes below them. Thus, metrics support process improvement, technolo desin and event manaement support intrusion analsis, etc.
Design
Event Management
Configuration Management
Daily Operations
System Administration
Training
TECHNOLOGICAL
OPERATIONAL
BC/DR
Process Improvement
Compliance
Metrics BUSINESS
Fiure 2: Process hierarch that shows the various SOC processes and how the build on each other.
ArcSight 5
Whitepaper: Building a Successful Security Operations Center
SOC processes are broken up into the four main cateories: •
Business processes: Document all the administrative and manaement components that are required to effectivel operate a SOC.
•
Technolo processes: Maintain all the information relating to system administration, conguration management and conceptual desin.
•
Operational processes: Document the mechanics of the dail operations, like shift schedules and turn-over procedures.
•
Analtical processes: Encompass all activities desined to detect and better understand malicious events.
orgniztin Rtinsips In addition to documentin the processes and procedures necessar to operate the SOC effectivel, the SOC must have a lare number of external relationships to effectivel manae a crisis situation. These relationships can include internal teams, such as: Incident Response, Securit Manaement, Securit Enineerin, Leal, Human Resources, Public Relations, and Lines of Business. Relationships will also include external teams like: CERT/CC, Information Sharin and Analsis Centers (ISAC), local and national law enforcement, supportin product vendors, etc. All the various points of contact (POCs) should be well-documented alon with how and when the SOC should involve them in a developin s ituation.
Dtctin vs. ansis There is a key distinction to use in developing SOC processes and procedures. Detection time is dened as the period of time from when an event is identied within the SOC to when the analyst makes a decision as to how to act on it. For example, an analyst detects a SQL injection attack aainst a monitored web server. She will then conduct initial research usin intellience about the various threats to better understand whether the event points to a true attack. After research, the analst will determine the priorit of the event and annotate the event. For example, a misconguration of the security device, a false positive event due to a faulty web app, worthy of additional monitoring attention, worthy of additional research, or a conrmed intrusion attempt to be escalated. The analtical time frame beins once operational time is past and continues for up to 90 das. After initial research, an analst will tpicall annotate an event for further analsis. At this point, the processes within the analtical time frame take over. More senior personnel will continue researchin the events, notif the necessar constituents, report the event, and perform forensic analsis as needed. Analsis continues as trends and lon-term patterns are analzed b visual data minin and other advanced analtical techniques. This distinction in timeframes, as shown in Fiure 3, will help to oranize SOC processes and clearl delineate roles amon the associated actions.
Advanced search / subtle event detection
Triage and initial research
EVENT DETECTION
DETECTION
OPERATIONAL DECISION
Forensics / reverse engineering
ANALYSIS
POINT
Threat intelligence infusion
Callout and notifications
Reporting
Fiure 3: Timeline for event detection throuh analsis
ArcSight 6
Whitepaper: Building a Successful Security Operations Center
Prcdr Fw Once SOC processes have been dened, the organization needs to take the next step in outlining the various procedures associated with each process. Each major area of process will have its own procedures. Here is an example from each area: PROCESS CATEgORy
SOC PROCESS
PROCEDURE
PROCEDURE DESCRIPTION
BUSINESS
Metrics Reportin
KPI Reportin
Outlines the steps involved in reportin the ke performance indicators (KPIs) of the SOC.
TECHNOLOgy
Sstem Administration
User Access Manaement
Details the steps necessar to request, approve, and rant access to the various SOC tools.
OPERATIONAL
Dail Operations
Shift Turnover
Outlines information to be shared and reviewed in shift los to ensure no information aps occur at shift chane.
ANALyTICAL
Intrusion Analsis
Threat Intellience
Enumerates the steps the level-2 analsts perform to ather up-todate cber intellience information, analze it for relevance, and produce a dail report for the analsts to read and leverae in their monitorin role.
Fiure 4 ives an example of the relationships amon the subordinate procedures. The core procedures documented in the circle should be areas of particular emphasis as these dene the basic actions to recognize and respond appropriately to detected malicious events. This also shows how all the supportin business and technolo procedures support effective dail securit operations.
Shift Turn-over
Daily Operations Call
Data Visualization
Information Fusion
Report Analysis
Core Procedures Crisis Response
Event Analysis Shift Schedule & Staffing
Periodic Reports
Incident Response
Callouts Monitoring
Incident Research
Triage Case Management
Training Use Cases
Incident Summary
Analyst Comments
Focused Monitoring
Problem & Change Operational Time
Modeling
Configuration Mgmt:
Applications
Analytical Time
Process Maturity
Access Management Key Performance
Indicators Compliance Support
Configuration Mgmt:
Internal Compliance
Business Continuity
Architecture
Documentation
Maintenance Informational Metrics Disaster Recovery
Agile Methodology
Infrastructure Performance
Figure 4: SOC procedure ow
ArcSight 7
Whitepaper: Building a Successful Security Operations Center
exrcis A ke item on the path to a full mature SOC is to conduct a full-scale exercise that includes the rane of process and procedures and leveraes all the internal and external relationships that have been built. There are a number of challenes that can be introduced to see how the SOC functions under considerable oranizational and situational stress, such as: Deradation of communications, unavailabilit of various SOC tools, and condensation of the available time. Once this exercise is complete all involved teams should conduct a group “lessons learned” review and address all identied weaknesses with more training or improved process and technolo.
Tcng One of the challenges for security operations is identifying signicant events from a large number of heterogeneous security devices and sstems, correlatin those event feeds, and reducin the overall event volume to a level manaeable b the analtical staff. Analysts may have to log in to a number of management consoles to investigate events while the sheer volume of events (e.g., rewall los) ma make it impossible to perform sensible analsis. In order to automate event collection and correlation, SOCs must deplo a Securit Information and Event Manaement (SIEM) solution. The ArcSiht SIEM solution is the premier solution for monitorin, investiatin, and respondin to malicious events. ESM takes the step beond storae and alertin to provide real-time monitorin and correlation, historical analsis, and the automated response necessar to manae the hiher level of risk associated with doin business in toda’s diital world. ArcSiht delivers real-time event management and “forensics on the y,” the ability to drill down from an alert to the source events that triggered the alert.
Fiure 5: Taret analsis usin ESM Interactive Discover
ArcSight 8
Whitepaper: Building a Successful Security Operations Center
Dt aggrgtin ArcSiht ESM can collect thousands of events per second, which are stored in a relational database for analsis, displa, investiation, and reportin. Data can be collected and areated in an aentless fashion b usin the ArcSiht Manaer and deploin various devices and concentrators throughout the network using ArcSight SmartConnectors. This results in several benets: •
Eas deploment to existin infrastructure without addin additional hardware or re-architectin existin devices and protocols.
•
Distributed data collection can utilize a variet of protocols ( e.., Checkpoint, Cisco SecureIDS, an SNMP, an sslo) while workin from a central ArcSiht ESM platform.
•
Secure communication occurs securely over existing IP or IPsec protocols and through rewalls conforming to standard security policies.
•
Abilit to scale to handle increasinl wider deploments that brin additional sources of information into the sstem without incremental installation and maintenance.
An important element of the ArcSiht ESM data areation strate is a complete capture of the status, alarms and alerts from the various rewalls, intrusion detection systems, and other relevant sources that are being monitored, no matter what topology of agents and centralized collectors is used. This means that every eld from every event is available for real-time correlation, display, investiation, and reportin. ArcSiht SmartConnectors support hundreds of products and can also: •
Normalize ever alarm and alert into a common secur it schema
•
Filter out unwanted trafc
•
Set severit accordin to a common taxonom
•
Intelligently manage bandwidth to minimize network trafc
Dt Crrtin While ensurin that the necessar data can be collected and centralized, a successful SIEM technolo should also be able to normalize, cateorize, and correlate the data across man technoloies. In particular a SIEM must be able to accomplish these eiht tasks: •
Normalization: A SIEM solution must have a robust data schema. In order to nor malize data across man different devices, the solution must provide enough data elds to add all of the necessary information from these devices so it can correlate aainst them. Without this data capabilit, a SIEM could not add or interate with multiple devices from disparate parts of the oranization—such as from network devices, securit sstems, servers, applications, phsical access, video analtic sstems and environmental controls.
•
Cateorization: The SIEM should provide an extensible taxonom to describe events in an easil understandable format, easil roup events b writin vendor-independent rules, and the abilit to seamlessl interate new devices.
•
Simple Event Correlation: The solution should be able to easil perform event areation and look at multiple events to detect somethin that would otherwise o unnoticed. This basic functionalit allows several events to be correlated, producin an outcome that is then re-evaluated against other events in the ow. For example, ve attempts to login to a system within one minute usin the same user account could be indicative of a brute force loin attempt.
•
Multi-Stae Event Correlation: The SIEM solution should be able to analze information from a variet of disparate events— sometimes three or more different events—to determine if the are all related to the same incident. For example, the SIEM should be able to nd the relationship between the rewall accepting the attack trafc and the attacked system communicating back out to the attacker. This combination must be picked out of the hastack of millions of events passin throuh the correlation enine.
ArcSight 9
Whitepaper: Building a Successful Security Operations Center
•
Prioritization: The solution should have the abilit to identif the business relevance of the taret in question as it relates to the organization’s business imperatives. If the target is a revenue-generating system or contains classied data, it s hould be given the hihest priorit. If it is a seldom-used sstem in a lab, it can be placed further down the list to be addressed when the event manaement team has time.
•
Statistical Analsis: A SEIM should have the ability to detect events of signicance by identifying mathematical deviations as anomalies from normal trafc such as sharp increases in activity on a particular port, protocol, or event type.
•
Historical Analsis: The solution should be able to provide historical or forensic information to help the SOC gure out what miht have been missed. This is impossible in solutions without an advanced correlation enine capable of reevaluatin past data to look for compromises that ma have one undetected. The potential attacker miht also be doin oranizational reconnaissance, slowl mappin out the network in preparation for launchin a full-scale calculated attack at later time. The SOC needs the abilit to detect unusual activit levels for lon periods of time before an attack is launched.
•
Phsical and Loical Analsis/Location Correlation: The solution should be able to perform both phsical and loical correlation. The SOC needs the abilit to correlate between phsical access sstems and loical securit devices—such as operatin sstem los or VPN data. This will provide the abilit to detect incidents such as account sharin phsical plus VPN access violation, a eoraphic access violation or suspicious phsical activit like after hours buildin access.
Smmr Desinin, buildin, and manain an internal securit operations center can dramaticall improve an oranization’s abilit to rapidl reconize and respond to malicious information securit events. A SOC can also assist in ensurin oranizations leverae the full value of the often expensive investment in securit technolo and meet a mriad of reulator compliance requirements. Approachin the challenge across the full scope of People, Process and Technology will ensure the SOC is up to the task of effectively and efciently reconizin and respondin to malicious events.
To learn more, contact ArcSight at:
[email protected] or 1-888-415-ARST © 2009 ArcSiht, Inc. All rihts reserved. ArcSiht and the ArcSiht loo are trademarks of ArcSiht, Inc. All other product and compan names ma be trademarks or reistered trademarks of their respective owners.
ArcSight 10
