Sample Mission Statements

Here are two sample SOC mission statements. As you read each mission statement, try to identify the answers to the questions provided in the preceding list. (The answers are given in the sublist following each statement.)

• Mission Statement 1: The security operations center (SOC) is responsible for monitoring, detecting, and responding to incidents and the management of the organization’s security tools, network technology, end-user devices, and other systems as assigned. The goal of the SOC is to reduce risk from cyberthreats targeting the organization. The function of the SOC is performed seven days a week, 24 hours per day. The SOC is the primary location of the staff and the systems dedicated for this function.

  • Purpose: Monitoring, detecting, and responding to incidents and managing security tools.

  • Customers: All end users employed by the organization and guest users.

  • Alignment to customer’s mission: Reducing the risk from cyberthreats targeting the organization.

  • Services: Incident management and management of security tools, network technology, end-user devices, and other systems assigned.

  • Service availability: Seven days a week, 24 hours per day.

• Mission Statement 2: The security operations center (SOC) monitors the overall security posture of the IT network. The goal of the SOC is to help the organization identify and respond to security incidents and return impacted systems back to a normal operational state in a timely manner. The security operations center responds and tracks security incidents with the objective of maintaining the overall security posture while reducing risk when possible. The functions are performed around the clock in support of the organization’s operation model.

  • Purpose: Maintaining the overall security posture of the organization while reducing risk when possible.

  • Customers: The organization.

  • Alignment to customer’s mission: Respond to security incidents and return impacted systems back to normal operational state in a timely manner.

  • Services: Respond and track security incidents.

  • Service availability: Around the clock in support of the organization’s operation model.

Each of these two sample mission statements represents a single SOC taking on most of the security responsibilities at the organization that it functions within. Statement 1 has more specific details, such as the days of operation and location, while Statement 2 is broader in how it explains its purpose. Both statements are fine; however, relegating items that could change to the scope statement is recommended so that the mission statement can endure relatively unchanged and represent the high-level goals. Statement 1 isn’t bad, but if the SOC changed its hours of operation or location, the mission statement would need to be adjusted. Statement 2 provides broader language for the hours of operation that would be ideal so specific changes in service availability won’t impact the mission statement. Both statements could also have more details regarding how they align to the organization, but are good starting points.

Scope Statement Challenges

A challenge that is common when creating the scope statement is committing to specific services. There might be questions regarding whether the SOC should be responsible for a particular service or another department should handle that service. For example, if the SOC scope statement claims responsibility for identifying vulnerabilities, does that mean desktop support is not responsible for identifying vulnerabilities? Who would handle remediating vulnerabilities? Would that be desktop support and/or the SOC? How would this handoff occur if the SOC does not handle remediating vulnerabilities and hands off systems identified as vulnerable to desktop support? Looking back at the language used in the first example scope statement, the statement points out that the SOC is responsible for only “discovery and tracking vulnerabilities.” The scope statement does not include the responsibility for remediating vulnerabilities, which means the SOC is not responsible for this service.

For this example, another team such as the vulnerability management team can have the responsibility of remediating vulnerabilities. The vulnerability management team can also have a scope statement claiming responsibility for identifying vulnerabilities, which would be an overlap in services offered by the SOC since it also claims responsibility for identifying vulnerabilities. If this situation occurs, both teams need to recognize this overlap in responsibility and develop a plan for how responsibilities are handed off and/or how these teams collaborate. The best approach to this specific example would depend on various factors within the organization. Some organizations might decide to remove vulnerability identification from the SOC’s scope, while other organizations might decide to remove vulnerability identification from the vulnerability management team’s scope, which would mean the SOC would identify vulnerabilities and hand off those findings to the vulnerability management team so the vulnerability management team can handle the remediation.

Governance and Risk Management References

Scope statements can also include concepts related to security governance and/or risk management. The purpose is to provide clarity regarding why specific services are being offered. For example, a scope statement may specify that the reason for providing data control services is to meet HIPAA or PCI DSS compliance. A scope statement can also relate to a business goal, such as to ensure an organization’s product is safe or service is always available to customers. Including clarity regarding the purpose of a SOC service helps leadership better understand the purpose of the service, leading to better support for the SOC. Another benefit of clarity is that those using or impacted by the SOC service will understand and respect why the service exists. Respecting a SOC service leads to less pushback when the SOC has to take actions.

Procedures Examples

Let’s look at an example of procedures associated with responding to a security incident. Procedures should specify which group is responsible to perform the first response to a security incident. Procedures should include the hours of operation for this team, steps to escalate the problem if it can’t be solved, steps to solve problems that fall within scope of the first responding team, what are the backup options when the team isn’t available, and what the first responding team is authorized to perform. If a new person is recruited to perform the first responder role for an incident, procedures will provide directions for how each of these tasks is performed.

Figure 2-3 is an example of creating a mapping of how a SOC supports a procedure. In this example, the SOC activities include monitoring alerts from three different groups. Tier 1 support handles monitoring, alerting, and escalating to tier 2 when an issue requires more skilled individuals who are authorized to perform such work. Tier 2 can also escalate to a more advanced tier 3 group when such skills are needed. Tier 3 support also includes additional SOC services such as forensics and malware investigation.

Figure 2-3 is great for a high-level view of SOC tiers; however, the communication between these teams isn’t defined. For example, how is tier 1 contacted? Who is authorized to escalate an event to a higher tier? Who handles logging and reporting? What if a tier is unavailable when contacted? Figure 2-4 provides a more detailed approach to documenting a procedure. For this example, the procedure diagram covers how customer inbound requests are handled. The helpdesk receives alerts through a phone call or email. Incidents are handed to a SOC tier 1 analyst, who can attempt to close the case or escalate the case through the SOC tier 1 supervisor or team lead. The SOC tier 2 attempts to handle an incident or pull in or hand off an incident to a tier 3 support member. Tier 3 members include external services they can leverage if they are unable to cover the incident with in-house resources. Know that this diagram can include even more details such as the names and locations of parties involved, specific tools available and hours of operation. Many of these details were omitted from the diagram for the purpose of providing a generic example.

Active Vulnerability Scanning

In order for a vulnerability scanner to detect and classify system weaknesses in computers, networks, and communications, it must have access to the target being scanned. Access can be from the network or directly on the host. The level of access can be full read-level access, known as authenticated scanning, or no ability to log into the system, known as unauthenticated scanning. Having full read access provides more details about how systems, networks, and communication are vulnerable. Results of authenticated scanning provide a more accurate report, which leads to a better remediation response. Although authenticated scanning provides better results than unauthenticated scanning, it does not realistically represent what a potential adversary will see. Unauthenticated scanning is considered the attacker’s point of view, meaning tools like firewalls will prevent some scanning use cases from providing any useful data. A SOC should use both authenticated and unauthenticated scanning to identify all potential vulnerabilities as well as understand how adversaries would view computers, networks, and communication they could target using the unauthenticated scanning approach.

Figure 2-5 shows an example using Rapid7’s Nexpose vulnerability scanner platform. The dashboard shows a summary of the environment being continuously evaluated for vulnerabilities, which can be broken down into sites or network segments. An example could be scans set up for different parts of the customer and SOC segments. In this example, a summary of the vulnerabilities found within each network segment is presented in two pie charts. The first pie chart rates vulnerabilities based on their CVSS score. The second pie chart ranks vulnerabilities based on the skill level required to exploit them. Below the pie charts are specific vulnerabilities identified by Nexpose. An analyst can click any part of either pie chart or the specific vulnerabilities listed to learn more about what Nexpose discovered.

Passive Vulnerability Scanning

Tools such as application-layer firewalls can gather data about endpoints and send that data to vulnerability scanners to perform passive scanning. I am finding that more security solutions are leveraging passive security technology with the intent of adjusting defense capabilities to systems found vulnerable. Figure 2-6 is an example of the Cisco Firepower solution showcasing passive vulnerability scanning information. This approach to passive vulnerability scanning works by leveraging the next-generation firewall’s capability of seeing all layers of traffic. This permits host profiles to be created, which are compared against a database of known vulnerabilities similar to an active vulnerability scanner. The difference between an active vulnerability scanner such as Rapid7’s Nexpose and a passive vulnerability scanner like the Cisco Firepower solution is that a passive scanner only sees what data can be profiled, while an active scanner can be configured to scan any network or host it can access.

The results of a vulnerability scan (regardless of which approach is used) will produce a handful of vulnerabilities found within computers, networks, and communication on your environment. Analysts will want to identify all systems that are vulnerable and create tickets to assign an engineer to patch these weaknesses. While systems are exposed, the SOC will work to prevent an adversary from exploiting these weaknesses using security tools such as an IDS/IPS and antivirus. Security tools can be tuned using results from vulnerability scanners to help protect computers, networks, and communication that have been identified as being vulnerable. Tuning security tools helps to protect vulnerable computers, networks, and communication from attack while the asset owner is notified to fix the vulnerability.

Preventive Technology: Firewalls

Firewalls and proxies can perform network segmentation and limit what ports, protocols, and applications are permitted to cross a network segment. Best practice is to enforce least privilege access through each network segment to reduce the risk of exposing vulnerabilities to adversaries outside of network segments. For example, if an organization doesn’t have a business need for permitting Tor traffic, this traffic should be prevented from crossing network segments. Blocking Tor reduces the risk of adversaries and malware communicating between a network segment and Tor network, which is common behavior for threats such as ransomware.

Preventive Technology: Reputation Security

Another preventive technology the SOC should use is reputation security. Reputation security reviews various factors of an external source and judges how trustworthy that source should be seen as. One factor is how long the source has been online. If a source claims to be an online bank but has been online for only a few hours, the source is not a bank. Another factor is the reputation of the domain owner. The current source being evaluated might be seen as safe, but if the domain owner has been flagged as being responsible for other malicious domains, that factor will impact the trustworthiness of the current source being evaluated. Another factor is the type of content that is being presented from the domain. If files that have been downloaded from a domain have been flagged as malicious, that will impact the trustworthiness of the source being evaluated. The list goes on for what factors could be evaluated, and different vendors will have a different approach to how reputation security is evaluated and enforced. An example of reputation security’s value is blocking an adversary from creating a malicious website that looks similar to a trusted site, which is a common tactic associated with phishing attacks. If an adversary attempts to create a fake website representing a trusted bank, factors such as the website only being online for a short time, being hosted from GoDaddy, and the domain owner being associated with other malicious websites would all impact this source’s reputation score. Figure 2-7 is an example of a Cisco block page triggered when accessing a web source with a negative reputation score. Security solutions leveraging reputation security will block the fake bank described in the previous example and display a page such as what is shown in Figure 2-7 based on how the vendor informs users of a source being blocked.

Similar reputation security technology can be used on other parts of the network such as host systems and email. Google Gmail is one of the many email services that have adapted reputation security to reduce spam and phishing attacks. Figure 2-8 is an example of a phishing email being flagged by Google as being dangerous based on various factors Goggle uses to flag malicious email. Factors can include the content of the email, the sender of the email, the audience that is receiving the email, and negative results associated with similar emails.

Preventive Technology: VPN

Virtual private networking (VPN) is another preventive technology. VPN reduces the risk of man-in-the-middle attacks because all traffic is encrypted. There are different VPN options a SOC can consider. For remote devices requiring access to secured network segments, the SOC can use different options for remote-access VPN such as Secure Sockets Layer (SSL)/TLS or IP Security (IPsec). A SOC can also use VPN to encrypt traffic between different segments such as a SOC headquarters and a branch office. Table 2-1 is a quick summary comparing the differences between remote-access and site-to-site VPN technology.

Preventive Technology: Network Access Control

Network access control (NAC) is a preventive technology that prevents an unauthorized device from connecting to the network. Because potential attackers don’t have an authorized device, they can’t connect to the network to attempt an attack. NAC can also enforce the principle of least privilege through provisioning predefined access to devices based on various characteristics. Networks for guest users can be limited to only what guest users need, such as only Internet access with limited bandwidth, while trusted employees can be placed on a network with more access capabilities. Controlling access is fundamental to enforcing proper network security.

Preventive Technology: Data at Rest/In Motion

Data at rest and data in motion technology can protect data from unauthorized access. Data at rest technology encrypts files containing sensitive data, preventing adversaries from having access to such data. Data in motion solutions, commonly called data loss prevention (DLP) technology, can prevent sensitive data from leaving the organization using pattern matching, such as identifying data with credit card numbers or other sensitive data. Cloud access security broker (CASB) technology can also perform data in motion capabilities by controlling who can access data within a cloud service to prevent it from being exposed to adversaries.

In summary, preventive means blocking the attack before it happens. Preventive technology can provide value at all stages of the Cyber Kill Chain and needs to be included in your SOC’s defense-in-depth strategy.

Detection Technology: NetFlow and NBAR

NetFlow and Network-Based Application Recognition (NBAR) can be used to detect threats based on how devices behave on the network as well as deviations from a baseline of those devices’ normal behavior. Both of these approaches offer a lot of value but have limitations in the details they provide about a potential threat. Packet capturing technology can provide more details than NetFlow, such as the specific file that was lost during a potential data loss incident, where NetFlow would only be able to provide records of the parties involved with the event. Records can include who sent the file, what protocols were used, the type of data, and other metrics depending on the technology being used and type of flow being collected.

Detection Technology: Baselines

User behavior can be monitored using detection capabilities. This technology baselines user login trends, what systems are accessing different parts of the network, where the user is located, and what level of access they should have. For example, if a user logs into the network from the United States and moments later logs into the same system from Russia, two different users likely are using the same account, meaning an account login has been compromised. Similar technology is becoming popular for cloud environments, particularly the previously mentioned cloud access security broker (CASB) that monitors access to services such as Dropbox and Salesforce.

Detection Technology: Honeypots

As introduced in Chapter 1, other popular breach detection tools are honeypots, systems designed to attract adversaries and malware. Like bears are attracted to honey, the concept of a honeypot is to attract attackers to a decoy system, diverting their attention and effort from valuable production systems. Malware and adversaries tend to attack what is perceived as the easiest target, and the honeypot system is configured with tons of vulnerabilities to catch their attention. The honeypot is accessible via the network but is firewalled from the rest of the network systems. This tactic can be very effective; however, some malware is designed to target specific behavior rather than exploit the weakest system on a network to avoid compromising a honeypot that would alarm the target of the presence of the adversary within the network. Honeypots also pose a risk to the network if they are not configured properly, such as configuring a honeypot with a public IP address while placing it within a trusted network. Any adversary outside of the trusted network can use this misconfigured honeypot as a gateway into the trusted network.

Chapter 1 covered security capabilities and how a SOC needs to layer different capabilities to develop a defense-in-depth approach to security. Defense in depth includes layering different types of detection and prevention technologies.

SOC Goal Alignment

Designing a SOC depends on a handful of factors. First off, the mission statement and scope statement set the boundaries for the location(s) where the SOC will operate. These statements also identify the different services expected from the SOC. Chapter 3 covers SOC services in more detail; however, understand that before a service can be offered, there must be people, process, and technology available to perform the service. That means the people and technology must reside somewhere and there will be expected resources available. Capacity planning ensures that those requirements are met.

Chapter 1 covered how to assess existing capabilities and available technology based on best practices from industry standards, guidelines, and frameworks. Assessing existing capabilities and available technology provides a blueprint of the current state of the SOC. Chapter 1 also covered how to use maturity modeling to develop a plan with milestones to improve SOC services. Those maturity goals include how the future desired SOC will look regarding people, process, and technology:

• People goals reflect the number of people for required roles as well as the expected skillsets. Some skillsets might be taught on the job while other skills will be required the day the new hire takes the role.

• Process goals impact what is required to deliver services. This includes what policies need to be enforced and how those policies are enforced.

• Technology goals complement the people and process goals, acting as an enabler to accomplish goals for SOC services. For example, a goal to monitor the network for threats requires technology that permits monitoring network traffic as well as tools for identifying when malicious activity occurs.

Growth Planning

Maturity goals influence the SOC’s capacity planning requirements. Planning must account for required hardware, number of employees, how teams will collaborate, seating arrangements, and many other factors that are needed to properly deliver a specific SOC service at the expected level of maturity. When considering the physical location for the SOC, one key principle is that choosing a location that the SOC can grow into usually is less expensive than having to move to a larger location at a later date because the SOC has outgrown its initial space. If the SOC capacity planning team is unsure about future requirements for the physical location, it is ideal to predict, at a minimum, a three- to five-year growth percentage and develop the location around those numbers. An example could be viewing the maturity goals for the SOC and target each SOC service to be at a specific state three to five years from the current date. Capacity planning must take into consideration what changes are needed in people, process, and technology to be at the three- to five-year maturity state. Using this approach leads to a SOC design that has a percentage of open seats, growth room for increased bandwidth usage, and available rack space for future technology.

If your SOC budget does not allow for including future growth in a capacity plan, there are other options that can be used as the SOC outgrows its physical location. Options include permitting teleworking, opening a new branch facility that is connected to the SOC headquarters, and/or outsourcing some services. Any of these options is more ideal than having to migrate an entire SOC and its people and technology to a larger facility while maintaining its services.

Technology Planning

Another capacity planning factor is related to the technologies used by the SOC. As technology capacity planning is performed, it is recommended to set up meetings with vendors of existing equipment within your organization so they can help future-proof their equipment. Vendors will also know the best options for configuration and hardware that meet your SOC maturity goals. It is best to start with existing vendors because they are less likely to have to “sell” against anybody else and they might already understand your environment. Even by doing so, you still might encounter a vendor attempting to upsell or displace other vendors within your organization. For example, if you have products from two different firewall vendors in your environment and invite each vendor to help you with capacity planning, each vendor will offer a future design that replaces the competitive firewall.

Another option for technology capacity planning that captures a vendor-neutral viewpoint is to seek consulting from technology service partners, also called resellers, that broker sales between your organization and vendors. Many enterprise vendors do not sell directly to customers but instead rely on resellers, which can provide the SOC with a comparison between industry leaders and advise on what other SOCs are doing in the specific technology areas of interest. Knowledge is power and there are likely many experts willing to speak with you at no cost regarding the best ways to design different parts of your network.

Before starting conversations with vendors or specialists, you will want to verify all hardware and connectivity requirements based on your SOC maturity goals. Remember that the requirements you develop are a starting point for the design; be prepared for outside specialists to suggest change. For example, some products can include proprietary components or have special requirements such as additional power. It is best practice to lead with technologies that are flexible by supporting application programming interfaces (APIs) and open standards; however, you will want to ensure capacity planning accommodates all requirements, including those systems that are not flexible regarding APIs and open standards. Sometimes you will find that some proprietary technology may be much cheaper and already used within the organization, while other times investing in the effort to convert to a new system will make more sense for your SOC. Chapter 1 provided details on how to assess for capabilities, plan for maturity, and rank which investment would provide the most impact to the organization. The results from these exercises will provide guidance for which technology options are best for your SOC.

SOC Resource Planning

It is important to include all teams that will work with the SOC during the SOC’s capacity planning. There might be areas of cost savings that could be accomplished by leveraging other teams’ resources, including using other teams as designated backup options. For example, another team might agree that its office space could serve as the overflow or emergency workspace for the SOC rather than having to build or rent a redundant location. Having conversations with other teams will involve budget, which can lead to sharing the cost of hardware and service support and consolidation of existing hardware. Working with teams outside of the SOC can help overcome challenges to certain SOC goals. An example is the SOC using the organization’s datacenter to host and manage its technical equipment rather than having the SOC responsible for datacenter management tasks.

Some capacity planning decisions will be influenced by whether in-house or external services are used. Once again, vendors and resellers can advise on the benefits from either approach, but keep in mind that vendors want to sell you something. Rely on your maturity assessments (discussed in Chapter 1) to help keep the conversation nonbiased and in the best interests of the SOC. Reasons for using external services in response to capacity planning are reductions and potential savings in hardware, personnel, required process, and compliance.

Redundancy Planning

Another capacity topic that you must address is the requirement for redundancy. Redundancy decisions are based on the SOC’s risk appetite (for example, backup systems can be configured as active, passive, or on demand) and redundancy plans are developed using in-house services, outsourced services, or both. Chapter 1 covered how to rank the importance of capabilities and services against the goals of the organization. Anything ranked as high importance requires active and more costly redundancy, while lower-ranked services and technology require passive, less expensive redundancy options or just an on-demand option if a backup of a service or technology is needed due to a failure in the primary offering. The section “Disaster Recover,” later in this chapter, looks at disaster planning concepts in greater detail.

SOC Interior Design Considerations

The following list highlights key aspects to consider for the SOC’s internal design:

• Lighting: Lighting should promote a comfortable working environment permitting the analyst to not only see well in his or her workspace but also the video wall monitors, if applicable. Decisions regarding natural lighting and artificial lighting are made based on the building design, budget, and security requirements. Specialized lighting might also be required for certain SOC functions, such as viewing server rack space or cables under a raised floor.

• Acoustics: Poor acoustics can be very disruptive to daily operations. SOC analysts will be collaborating over the phone and within their teams, which will create noise. Noise levels need to be accounted for so that analysts can hear clearly during phone conversations. Also consider noise from equipment, which may necessitate placing it in a separate room such as the computer room rather than in the SOC analyst work area. Soundproof material for the walls could be used to reduce sound levels as well as protect conversations from being heard by unwanted parties. Audio privacy rooms can be built as an escape from noise as well as to ensure privacy of conversations. ISO 17624:2004 also provides guidelines for leveraging acoustical screens as an option to reduce office noise. All of these options can be used to promote a healthy and productive work environment.

• Security: Every SOC will have specific requirements about who can and cannot access the operations room. Physical security must be part of the design of the SOC facility. Common options are door locks, common access card (CAC) or other smartcard door locks, video monitoring, and mantraps. Additional specialized lighting might be required for certain situations such as when visitors without clearance are in the SOC facility. I have been in SOCs that use police lights that are enabled when an uncleared person enters the SOC, notifying all analysts to turn off their monitors and the video wall screens while the person is present. External consultants can assist with meeting your SOC’s security requirements and can advise on any constraints such as if CCTV is not permitted within a country.

• Secure disposal: People will produce trash that contains sensitive information. A SOC must have requirements for properly shredding and disposing of such trash. Dumpster diving is still a threat to modern organizations. Purchasing professional trash disposable services or tools such as shredders to accommodate securing trash are some options that are available.

• Storage: Certain types of data might require specific storage requirements. For example, classified documents or forensic evidence will have to be bagged, tagged, and stored securely. Secure storage needs can require a safe or other storage options, perhaps even a specialized part of the building with armed guards, known as a sensitive compartmented information facility (SCIF), discussed further in the next section.

• Video wall: Some SOCs use monitors that enable multiple analysts to view the same data simultaneously. This means having view of multiple dashboards, which will likely need to be placed on a wall so all analysts can see the data. For example, a SOC responsible for various services may display the dashboard for a SIEM or other tools that take into consideration the SOC’s current event workload as well as external data such as global events. Having a centralized monitor allows each SOC analyst to focus on their own responsibility while always having a view of data that applies to the entire organization. To maximize collaboration, analysts should have access to the same data on their personal computer as well as be able to share what they are looking at on a shared video wall. Make sure that the video wall is high enough that all analysts can view it, including if somebody in the front row is taller than an analyst in the back row. Also consider future systems and analysts that might be added according to the capacity planning report. Figure 2-10 shows an example of how to design for these items.

  

• Workstations: Consider the workspace for each SOC employee type. For example, should it include a phone, a desktop computer, and possibly a mounted flat-screen monitor? Some analysts will use a laptop only and not need a monitor, while other analysts will prefer having multiple monitors. Consider the number of cable holes that are available to help conceal power and network cables. The layout of how workstations will look can be divided into separate cubical work spaces, grouped into a large workspace, or possibly be a long table that permits open seating. Many office equipment manufactures offer options for configuring workspaces, which is ideal so that the SOC can adjust to the most effective layout (which fulfills the previously discussed WBDG recommendation for flexibility). Speak with an office furniture specialist for more information about workstation furniture options.

• Lockers: Providing lockers gives SOC personnel a secure means of storing personal items. There may even be compliance requirements, such as no mobile devices permitted in the SOC, that necessitate provision of lockers. Lockers can also be placed within personal workspaces for storing smaller personal items and documents.

A final factor to consider regarding the value impact of the SOC’s interior design is the SOC’s aesthetic appeal. Do not underestimate the value of a first impression when people walk through a functioning SOC. Many SOCs offer the option to provide tours, enabling non-SOC members to gain awareness of the SOC and its associated activities. Investing extra effort in aesthetics can capture additional funding and support from leadership, who may include the SOC in tours of the company to showcase the company’s investment in security.

Computer Room Considerations

The following key topics must be addressed as planning occurs for a computer room that will be used by the SOC:

• Power requirements: The first step for planning power requirements is to determine the number of services to install per rack. Some equipment might need special power, such as more current, that would require an electrician to set up. There might be requirements for power strips where large amounts of gear will be located. To avoid blowing fuses or equipment, I recommend gathering your power requirements based on capacity planning reports and speaking with an electrician about what can and cannot be supported. Power redundancy is also an important topic. Impacting factors include the type of redundancy that can be provided, the budget for redundancy options, the available power supplies in equipment, and risk tolerance. One option for power redundancy is a single redundant option, meaning if a primary system powerline goes down, a backup power source takes its place. Grid redundancy is another option, which means to have twice the number of power supplies on the same system, with each power supply using a different AC power source.

  Power loads are dependent on the facility input plug. If the power load exceeds the rating on the input plug for a sufficient period of time, the input breaker will be triggered, causing the power to be disrupted. For this reason, power plugs need to be evaluated to ensure they can support expected power requirements based on capacity planning needs. This includes consideration for the different types of plugs used in different countries.

  The Uptime Institute offers estimates for the expected power usage of different size computer rooms, which can be helpful for budgeting for power. For example, the Uptime Institute estimates that 1 kilowatt of server capacity costs US$25,000 for a Tier IV datacenter. See https://uptimeinstitute.com/ for a better understanding of estimated costs for powering a computer room and associated equipment.

• Temperature and humidity: The American Society of Heating, Refrigeration, and Air Conditioning Engineering (ASHRAE) Technical Committee 9.9 has created a widely accepted set of guidelines for optimal temperature and humidity set points in the datacenter. For example, the ASHRAE guidelines specify acceptable temperature ranges for the datacenter to prevent IT gear from overheating. Cooling options include server racks that have built-in cooling, cooling the server room, and HVAC filters that suck heat out of a computer room or individual server rack space. Warm rooms can produce mold, which is bad for equipment. You might need humidity units, which will require some method to be drained as they collect water. It is best to have a sink that humidifiers can drain in rather than manually having to empty a humidifier.

  Table 2-3 represents ASHRAE recommended temperature and humidity ranges for a computer room.

  Property	Recommended Value
  Lower limit temperature	64.4°F [18°C]
  Upper limit temperature	80.6°F [27°C]
  Lower limit humidity	40% relative humidity and 41.9°F (5.5°C) dew point
  Upper limit humidity	60% relative humidity and 59°F (15°C) dew point

  Measuring temperature and humidity needs to be properly done to ensure that accurate readings are taken relating to all systems within the computer room. One side of the computer room may be hotter and moister than another side, so both sides need to be monitored. The design of the computer room can also impact airflow, permitting better control of temperature and humidity. Figure 2-11 is an example of air flowing through a computer room.

  

  Cisco published a site planning guide titled “Data Center Power and Cooling White Paper” for power and cooling that includes recommendations for the location and use of equipment racks in regard to their impact on temperature and humidity. One recommendation is to consider the arrangement of hot and cold aisles of a server rack. Arranging racks into rows of hot and cold aisles minimizes the mixing of air, reducing temperature and humidity. If two hot aisles are permitted to mix air, cooler air-conditioning requirements will be needed to compensate for the additional heat. Figure 2-12 is an example of how a hot-aisle and cold-aisle layout could look.

  

  The Cisco guide suggests powering the heaviest and most power-dense equipment at the bottom of the rack. This helps lower the rack’s center of mass to reduce the risk of tipping. Power-dense equipment tends to draw more air and need the most cooling. Many datacenters have cooling near the bottom of the rack to give the hottest equipment the coolest air. Cisco also recommends, when possible, to leave unoccupied space in the rack between servers to permit airflow. Unoccupied rack space can be filled with blank panels to keep the airflow within the server space.

• Equipment racks: Different types of equipment have different rack requirements. Server racks are different from network gear racks. Make sure to consider what type of gear would need to be stored or racked. Racks that have perforated front and rear doors to maximize air flow are ideal. You might need cable plants that can accommodate different types of connection types such as fiber and CAT6 with booted RJ45 connectors. Optional casters should exist to permit rack mobility if needed. Locks should be available to secure access to the equipment within the rack. Consider removable rack doors to simplify maintenance of systems within the rack as well as the rack itself. Finally, as previously discussed, consider the heat and humidity impact based on how racks are positioned within the computer room as well as the equipment within the racks.

• Lighting: Consider how the computer room is lit. Cabling can become extremely difficult to identify in a poorly lit computer room. Make sure your lighting accommodates people and the types of spaces they will have to work out of, meaning that if a tech is expected to go within a rack, there should be lighting that allows the tech to have full visibility of the equipment within that space. Emergency lighting should be available if the primary facility power becomes unavailable.

• Redundancy and UPS: The SOC deals with sensitive data that needs to be available even during a power outage. Redundancy can be accomplished through hardware, a backup location, routing, software, and backup power. For example, a dedicated uninterruptable power supply (UPS) or an existing UPS that supports the facility the SOC resides in can provide redundant power options. Backup routing options can be designed so that if a primary system goes out, traffic is routed to another location. Backup systems can sit at branch offices or within the cloud. Software can be configured to fail open or fail closed based on its business function. For example, a network access control solution could be configured to permit all connections (fail open) or deny all connections (fail closed) if a system failure occurs.

  Regarding expected costs for UPS support, a good guide is a whitepaper titled “Comparing UPS System Design Configurations” by Kevin McCarthy and Victor Avelar, which suggests potential costs associated with increasing the level of redundancy for a UPS architecture. As more scales of availability are added to the design, the cost per rack increases. McCarthy and Avelar use the following terms for UPS configurations:

  • Capacity: A single UPS system with no redundancy, meaning no backup system in place.

  • Isolated redundant: The traditional active standby two-system design where the primary system takes on all the load and the standby system is not used unless an event occurs.

  • Parallel redundant: Two systems activity sharing the load being used.

  • Distributed redundant: A few UPS systems are all sharing the load in an active manner.

  • System plus system: Systems not only are sharing the load but also have an additional local redundant system for backup if the local primary system goes down. An example of a system plus system design is having three facilities sharing the power load as well as each facility having a parallel redundant system.

    Table 2-4 represents the estimated costs associated with each UPS design according to the McCarthy and Avelar whitepaper.

    Configurations	Scale of Availability	Tier Class	Datacenter Scale of Cost (US$)
    Capacity (N)	1 = Lowest	Tier 1	$13,500–$18,000/rack
    Isolated redundant	2	Tier II	$18,000–$24,000/rack
    Parallel redundant (N+1)	3
    Distributed redundant	4	Tier III	$24,000–$30,000/rack
    System plus system (2N, 2N+1)	5 = Highest	Tier IV	$36,500–$42,000/rack

  • Grounding: All datacenter equipment needs to be grounded. This can be part of the equipment rack or require additional work. Ensure ground resistance is at least < 1 Ohm. There are many standards and guidelines that can be referenced for grounding best practices. NIST offers recommendations for grounding based on papers titled “Ground Connections for Electrical Systems” (Technologic Papers of the Bureau of Standards No. 108) and “A Consensus on Powering and Grounding Sensitive Electronic Equipment.”

  • Raised floors: If the SOC plans to host a lot of equipment, that equipment will require cables, which can get really messy. Computer rooms can be built on raised floors to hide cables and power connectors. Figure 2-13 is an example of a raised floor tile. Another option is running cables and power connectors within the ceiling, which requires a ceiling that can support the associated weight. Speak with a facility specialist to confirm that the ceiling or floor option used to host cables will meet your capacity planning requirements.

    

• Fire safety: Different countries have different required fire safety codes. Sometimes, fire safety options can put equipment or people at risk when they are released, such as chemicals that can quickly put out fires but are poisonous to humans. Water may be safe to humans but is bad for equipment. You will have to consider all of these factors, including the different types of fires that could occur. For example, an electrical fire is different from a gas fire and requires a different form of fire safety to be put in place. You may need a professional to look at smoke detectors and carbon monoxide detectors to accommodate all of these factors. ISO/TC92, Fire Safety, is one of the many guidelines that you could reference to address the different types of fire safety risk.

• Flood protection: The SOC facility could be at risk of flooding based on where it is located. Pumps and drains are countermeasures that can be put in place to handle a certain level of flooding. Water-resistant material and water barriers are also options to reduce the risk of flooding. The WBDG article “Flood Resistance of the Building Envelope” provides methods to evaluate if your facility is located in an area prone to flooding and describes various flooding countermeasures. Table 2-5 is WBDG’s overview of active and passive floodproofing methods.

  	Dry	Wet
  Active	Temporary flood shields or doors (on building openings)	Temporary relocation of vulnerable contents and equipment prior to a flood, in conjunction with use of flood-resistant materials for the building
  	Temporary gates or panels (on levees and floodwalls)
  	Emergency sand bagging
  Passive	Waterproof sealants and coatings on walls and floors	Use of flood-resistant materials below design flood elevation (DFE)
  	Permanently installed, automatic flood shields and doors	Installation of flood vents to permit automatic equalization of water levels
  	Installation of backflow prevention valves and sump pumps	Elevation of vulnerable equipment above DFE

• Monitoring: All electronic equipment needs to be monitored to ensure that accessibility and acceptable performance levels are maintained. It is recommended to have a central monitoring console located outside of the computer room that is monitored 24/7 for this purpose. Some SOCs assign monitoring to the NOC or a third-party consulting company, while other SOCs monitor equipment using in-house resources. Monitoring can include ensuring power is being distributed, systems are reachable, and systems are functioning properly. An example of a network monitoring tool is WhatsUp Gold from Progress (formerly Ipswitch). This tool continuously pings network-based equipment and alarms administrators when a system in found to be unreachable. NetFlow tools can be used to alarm when spikes or drops in network bandwidth are identified. Cisco Secure Network Analytics (formerly Stealthwatch), SolarWinds’ Network Performance Monitor, and Plixer Scrutinizer are examples of NetFlow-based network monitoring solutions.

• Locks: Systems in the computer room are critical to the operation of the SOC and need to be physically protected. Locks on the doors and server racks within the datacenter provide physical security and can be lock and key or based on various types of digital systems. Examples of digital systems include smartcards and biometric-based devices. Ensure that access to power and network cables is also secure. You want to avoid scenarios such as a cleaning person unplugging a critical system by accident during a standard cleaning routine. FIPS 140-3, Security Requirements for Cryptographic Modules, also provides guidelines to using locks to enforce proper physical security.

• Video and access control: A common requirement for a SOC computer room is the capability to control who accesses the room and monitor what they do while in the room. Access control can be based on physical controls such as mantraps and what type of locks are used on the doors within the SOC and its computer room. Various forms of video surveillance equipment can be used that are always active or triggered when motion is detected. Some SOCs require video surveillance to be recorded and stored for a specific period of time. The specifics of the video and access control requirements will depend on your SOC’s business needs in regard to physical security for the computer room. ISO 22311:2012, Societal security – Video surveillance – Export interoperability, is one of the many guidelines available that can provide recommendations for computer room physical security and monitoring options.

Logically Segmenting Hardware

Another logical segmentation option is to configure one physical piece of hardware to be recognized logically as more than one solution. An example is configuring a physical firewall to act as multiple logical firewalls. Configuring a physical firewall to be viewed as multiple logical firewalls is known by some vendors as multi-context mode. This feature is great for maximizing an investment in technology because logical separate versions of the same technology can be dedicated for different purposes. Sometimes the segmentation can be at the administration level, meaning administrators can make changes and see everything while other users can only see or change part of the system based on their login rights. Other times, such as in the multi-context firewall example, the firewall hardware views the different logical firewall segments as isolated separate systems that are unaware of each other. Multi-context firewall deployments are popular for service providers that sell access to datacenter services and deploy virtual firewalls dedicated to each customer so that the customer can manage and protect their rented virtual space. The SOC can use a single firewall and virtually dedicate separate firewalls for the analyst network, the testing network, and the management network.

ACL Segmentation

You can use access control lists (ACLs) to filter what can and cannot pass on the same network. An example of using ACLs could be permitting analysts full access to the Internet from the SOC network while limiting network access to guests visiting the SOC based on ACLs denying specific ports and protocols. There are many ways to use ACLs, including dynamic ACLs that can be pushed down by security tools if a policy is triggered. Regardless of your choice for VLANs, ACLs, or security group tags (SGTs), which are yet another way to perform segmentation, I advise not to overcomplicate your network design, or you will create a lot of unnecessary management work that will lead to confusion and unwanted disruption of services.

Determining Throughput Requirements

One important task in network capacity planning is determining the required amount of throughput for the SOC. Not properly sizing throughput can slow down or even render some SOC services and capabilities unavailable. An example is an interruption in connectivity between a system dedicated to monitoring various SOC tools for availability. If the monitoring tool believes systems are down, it can trigger a failover, which could cause wasted effort to reset all tools back to the primary state. Another example of the impact of not properly sizing the throughput for a SOC could be having the network become extremely slow when a large number of devices connect to the network around the same time. This could occur in the morning when everybody arrives at work or right after lunch when most people return from their break. Capacity planning needs to include a proper method to predict throughput to avoid these situations.

You can measure and predict needed throughput in a few ways. One way is to consider the number of users that will connect to the SOC’s network. Each user will use some level of office Internet bandwidth. The amount of Internet bandwidth can vary from 10 × 1 Mbps to 300 × 20 Mbps depending on the number of users and devices being used. This can depend on whether expectations for each user are for light, moderate, or heavy usage. Light usage would include email and Internet, which may be what a manager would use. Moderate usage includes file downloads, streaming music, Voice over IP (VoIP), and cloud-based resources. Heavy usage includes large file downloads, intense Internet application use, multiple devices, and interactive web conferencing.

The following are some expected bandwidth values associated with common actions that occur on a network:

• Opening a webpage: 1 Mbps

• Watching a live streaming video at 720p: 5 MB/minute

• Skype video calling: 28 Mbps/second

You can use tools to test and validate throughput. Online sources such as Speedtest.net offer a free method to identify current throughput levels. Vendors such as SolarWinds offer network throughput tools that can also provide an estimated report of throughput usage. Whatever estimated throughput requirements you develop, you must also consider other factors beyond your current throughput readings. The following are additional elements that you need to consider in your throughput capacity planning:

• Network peak possibilities: Estimate how much throughput would be required in a situation in which the maximum number of users need throughput. An example is accommodating for an event that causes all local and remote employees to connect to the network simultaneously.

• Average bandwidth requirements: What is the average usage? Tools such as Speedtest.net and SolarWinds Bandwidth Monitor (free tool) can capture these readings.

• Expected growth: What is the expected growth in the number of users and devices. Expected growth in the number of devices should include expectations for Internet of Things (IoT) and other types of devices that are not run by an end user.

• System throughput dependencies: All systems expected to connect to the SOC network need to be evaluated for throughput dependencies. The vendor’s website or product documentation can provide this information.

• High-availability/failover throughput considerations: Some high-availability configurations will have specific throughput requirements to ensure primary and redundant systems can monitor the status of one another.

• Possible traffic shaping options to reduce throughput needs: Consider the configuration options within switches and routers to reduce throughput needs.

As you perform capacity planning for throughput, make sure to consider how traffic will change throughout the year as well as future growth rather than assuming current throughput numbers are good enough for the next three to five years. Getting a feel of what throughput would be needed the next three to five years might require sampling at different times of the year to get a more accurate view of actual bandwidth usage. You need to also consider what new services and capabilities the SOC plans to add based on maturity planning for SOC services. I recommend sizing at least 10–20% room for growth on top of the current throughput needs and expected demands from new SOC services and capabilities. If the SOC experiences bandwidth problems, you can free up bandwidth by using tools and tactics to adjust how the network is used. Best practice is to not depend on filtering tactics for acceptable throughput.

Inline Connectivity Risks

There are risks of having traffic flow inline through a security tool. The first risk is that the security device becomes a bottleneck for network throughput. For example, if a 10 Gigabit Ethernet network flows inline through a 1-gigabit firewall, then the users on the inside network can receive at most only 1 gigabit of traffic because the firewall can’t deliver anything faster. Another concern is that having traffic flow inline through a security tool could create a single point of failure. To resolve this risk, an inline device can be configured in a fail open mode so that if the software fails, traffic can still pass through the device. Doing so essentially turns the device into a hub while the actual security aspects of the product are offline. Use cases might exist that warrant a configuration of a SOC tool to fail closed, meaning disabling the network connection while security is not functioning.

Risk Reduction with Redundancy

You should also consider redundant hardware and networks to reduce the risk caused by an inline device or other network bottlenecks from failing. Include redundancy for all critical systems as well as systems responsible for time, access control, event logging, and any other critical SOC service. Including redundant systems is also useful for performing upgrades that require a system to be rebooted, so that the secondary system can act as the primary is upgraded. You can accomplish redundancy by purchasing duplicate equipment or by using an alternative network path. If devices on one network are found to be unavailable, systems accessing those devices are instructed to go to another network to obtain the same resources.

The following are key terms for understanding redundancy options:

• Failover: When a primary system goes down and a second system immediately takes over the primary system role.

• Hot standby: When one system acts as the primary while another system waits in a standby inactive mode. If the primary system goes down, the standby system is running and ready to become the primary.

• Cold standby: When one system acts as the primary while another system is powered off and assigned as the backup system. If the primary system goes down, the cold standby system must be powered on and set up to take on the role as the primary system.

• Subscriber state failover: When a failover occurs, the backup system maintains the subscriber state. An example is if a primary access control system goes down, and the secondary system is capable of taking over the load as well as maintaining awareness/logging of systems that were logged by the primary system.

• Failure detect: The method used to determine if a primary system is no longer available.

NIST 800-123, Guide to General Server Security, is one of the main standards, guidelines, and frameworks that can be leveraged to learn more about proper redundancy tactics. Redundancy options will vary depending on the technology you are using.

Profiling

A SOC needs a method of validating devices on network segments based on MAC address or more advanced profiling tactics. Without this capability, a SOC network administrator will not be able to determine what type of device has connected to the network. Profiling a device beyond its MAC address is a more ideal approach because it uses various network protocols to ensure the device is authenticated, rather than relying solely on a MAC address, which could be spoofed by an attacker. For example, profiling technologies can determine the difference between an iPhone and iPad even though both products are made by Apple and have similar hardware components. Determining the difference between two different Apple devices can be based on how the DHCP request is seen, what version of Safari is used, or other factors analyzed by the profiling technology. Specific characteristics can also be used to determine not only if the device is what it claims to be but also if it is authorized. A common example is determining if the same device type is company issued versus an unauthorized personally owned asset. MAC addresses can be used for this purpose but, again, could be spoofed. Best practice is to use characteristics within the system such as placing a certificate on the asset that can be validated to ensure the device is issued by the organization.

NAC Value

Leveraging a NAC solution is recommended by many frameworks, including NIST’s Cyber Security Framework and ISO/IEC 27001. One popular choice is to use a centralized policy monitoring and enforcement NAC solution based on the IEEE 802.1X protocol. NAC enables a network administrator to limit certain users or devices to specific access privileges, enforced automatically upon connecting to the network. For example, Anjelica, an administrator, can bring her laptop, printer, and VoIP phone to any office within the SOC’s building and just plug them in. Based on the NAC profile for those devices, her printer would be placed on a dedicated printer network, her VoIP phone would be placed on the IP phone network, and her laptop would be placed on the administrator network. If a guest unplugs any of Anjelica’s devices and plugs in his or her own computer to the network, the network would change that port to the guest network based on how the guest authenticates and the type of device being plugged in. In this example, the guest’s device would not have the company certificate installed on the device connecting to the network and the guest user would not have an employee account within the accounting system. This would cause the guest to have his or her computer automatically placed on the guest network. This is just one of the many deployment options for a NAC solution—the default action the guest experiences could be complete denial of access or possibly provisional access, but an ACL would limit this guest user from administration-level access even though this user is on the same VLAN as Anjelica.

Regardless of how you deploy NAC technology, it is critical to ensure similar security is deployed across all areas and networks, including the LAN, wireless, and VPN networks. I have seen organizations deploy secure wireless while their LAN is open to anybody plugging in any device as long as they can get access to a LAN port. Best practice is to standardize on a network access policy across all access methods.

Additional value can be obtained from using a centralized network access control solution. Many NAC solutions offer the capability to share the database of network-connected devices, which is known as context. This database of connected devices can be used by other solutions, such as a SIEM solution, to match an IP address that the solution sees to what content the NAC solution knows about that IP address. An example is logging into a SOC’s SIEM solution and identifying every device that is on the SOC network by username rather than by IP address. This can occur based on the NAC technology capturing the user’s identity when the user accesses the network and sharing the database of users on the network with the SIEM technology.

Another value of a NAC solution is the capability to remove devices off the network that have violated a policy or are seen as a risk to the organization. Many NAC solutions scan a device as it attempts to access the network and verify that the device has required security features enabled before permitting access. For example, the SOC can use a NAC technology to validate whether a device connecting to the SOC network has antivirus installed and running and, if it doesn’t, deny it network access. NAC technologies can also be integrated with vulnerability scanners. A vulnerability scanner will scan the network and identify any device that has vulnerabilities. Devices that have critical vulnerabilities are labeled with a very high vulnerability score. A NAC technology can be used to automatically remove devices that have very high vulnerability levels. Figure 2-19 is an example of SANS’s recommendations for vulnerability management. Combining the value of a vulnerability scanner and NAC solution can automate the entire process recommended by SANS.

LAN Encryption

The LAN can also use encryption, which could be accomplished using tunneling technology, such as IPsec or SSL encryption, between hosts and servers or specific hardware-encrypting devices that sit between different parts of the network. The difference between encryption options include the following:

• Encryption strength

• How encryption keys are managed and exchanged

• What interfaces, protocols, and ports are used

• What OSI layer they run on

• Ease of deployment

• Speed

A site-to-site VPN can be used to connect two locations together. A SOC can use a site-to-site VPN between a branch office and headquarters to protect traffic as it moves between locations over an untrusted network. A similar concept can be used between a host device and the SOC network, which is ideal for SOC employees that need to access the SOC network remotely. I recommend speaking with the vendor of your network equipment to learn more about what encryption options are available. Table 2-1 from earlier in this chapter provided a quick summary of a site-to-site VPN and remote-access VPN.

NetFlow Technology

There are different types of network flow technology options depending on the vendor and version enabled. Examples include sampled flow (sFlow) and Juniper Networks’ J-Flow, to name a few. Comparing the value of a sampled flow such as sFlow against a data-rich option like NetFlow 9 could mean the difference of knowing an event occurred over the last 24 hours (sFlow) versus knowing that a specific action occurred on a specific part of the network from a specific device at a specific point in time (NetFlow). The reason for this difference is that sFlow uses time-based sampling counters while NetFlow uses cached flow entries from the hardware producing it.

NetFlow tools can offer different capabilities based on what the tool can do with the flow that is collected. Many flow tools can alarm for unusual traffic patterns to enable network techs to determine routing problems or areas that are underperforming. This can be useful for detecting network congestion so that alternative routing or other adjustments can be made to improve the overall network performance. Using NetFlow for improving network performance is useful; however, many of these same tools do not have algorithms to detect a port scan or worm activity. Products such as Cisco Stealthwatch and Plixer Scrutinizer are able to convert flow data into security events. Examples of security events include port scanning, worm propagation, data exfiltration, and denial of service.

There is a lot of value from NetFlow if an analyst is able to view all of the records. NetFlow is based on one-way communication, meaning the action of a user connecting to a server and the server responding will equate to multiple NetFlow sessions because each step of the connection will be a single NetFlow record. Multiply each single NetFlow log created as a user continues to use the network by the number of users on the network at any given time and you get a lot of NetFlow records to search through. If a NetFlow tool is only collecting NetFlow records, that tool will quickly fill up with more data than an analyst will be able to review. To deal with this issue, NetFlow tools with deduplication and stitching capabilities can remove duplicate records and stitch the entire session together to simplify mining large amounts of NetFlow data. One user going to a server may create multiple NetFlow records, but a single event can be recorded after all of those NetFlow records are stitched together.

Network-Based Application Recognition (NBAR) is another network protocol that provides intelligent network classification for network infrastructure. NBAR recognizes a wide variety of applications, including web-based applications and client/server applications that dynamically assign TCP and UDP port numbers. Once applications are classified, they can be monitored by security technologies as well as provisioned specific bandwidth through various network policy–based tools. Many NetFlow tools from vendors such as Cisco, SolarWinds, and Plixer also offer the capability to digest NBAR, the results of which complement what is found with NetFlow data.

There is a lot of value from using NetFlow and NBAR; however, these approaches to monitoring data cannot offer the same level of details as using a packet capture technology. Think of the value from the NetFlow approach as giving you the headlines of security events. This includes providing metadata timestamps, senders’ and receivers’ IP addresses, ports used, length of conversation, and amount of data transferred. SOC services such as incident response need accurate details of an event, which NetFlow and NBAR cannot provide. When this need comes up, the SOC must use another source that provides more details.

Packet Capturing Technology

Packet capturing provides the full story, accurately reconstructing what exactly happened and when it happened. The difference between analyzing flow and analyzing a packet capture is analogous to the difference between reviewing a list of phone calls made (flow) and recording the actual calls and listening to them (packet capture).

Packet capturing must store the traffic and a tool must be used to analyze what was captured. This requires large storage systems, leading to a higher cost. Flow can help you to determine where to look, but many flow-based tools lack evidence of whether an event is genuine, meaning you know an IP address violated a policy, but you don’t have the details of what was actually done, as you would if you have a packet-level capture of the activity. An example of details that packet capturing would include that a flow approach would not is the specific files that were exported off the network during a security incident. Having this level of detail would determine the value of the files that were lost, giving the SOC the specifics needed to apply the appropriate response to the incident. If the data was classified or protected by law, the SOC would be required to release to the public what was lost. It would be ideal to use the flow approach to view the network for threats and use the packet capturing approach to investigate a threat, but that is possible only if funding permits acquiring both of these types of tools. Either approach is ideal for monitoring the internal network for threats, but cost will likely cause you to initially invest in only one of these options. The good news is that vendors of either approach are starting to offer hybrid options, which will use flow to baseline the network and launch a packet capture upon seeing an event.

Reducing Events Per Seconds

To reduce the impact from chatty devices, you can implement tuning and storage to reduce the ESP. You can tune devices to generate a log based on the type of event. When debugging a device, you can enable logging for every single event, and when monitoring a device, you can restrict logging to only when a critical action is encountered. Figure 2-25 is an example of alerting levels available in some Cisco products.

Another approach to reducing the impact of EPS is to adjust the amount of data included within an event. Including more details about an event helps the analyst understand why the event occurred but also increases the requirements for storing these types of events. It is recommended to reduce the level of event details to only what an analyst requires to understand the event. Metadata could also be used instead of including the full log message, which would reduce the size of the log message. Some data fields may not provide value, in which case you can configure the tool generating the log to not include data from those fields. Consider all of these factors as you tune how tools will produce events. This will save you time on tuning, save money by enabling you to size monitoring products accurately, and improve the quality of the data being analyzed.

Storage and Data Retention

Another sizing concept to consider for SOC tools is sizing required storage and data retention requirements. For example, if three years’ worth of log data must be stored before records are purged, you will need to look at the impact of EPS on available storage and size accordingly. Sometimes, data retention requirements have different on-box availability needs versus having the data stored and encrypted off box in the event the data is ever required for a future investigation. This could be based on capability goals or required by a regulation such as Sarbanes-Oxley (SOX) or North American Electric Reliability Corporation Critical Information Protection (NERC CIP), to name just a few U.S.-specific examples. It is common for security tools such as SIEMs to carry data for one to three years and export details for anything older to a separate storage system, in a compressed format to save space. If older data is required, there is a process used to identify the record, uncompress it, and upload it back into the SIEM solution. Some security tools such as NGFWs might store data locally only for a short period of time before an off-box storage option is needed. It is important to cover data retention options with the vendors of the products you choose to use and ensure they meet your SOC’s requirements.

General cost can be another factor that determines what data is kept on box and when data is exported to an external storage system. It is common that an organization requires at least a year’s worth of log data that is ready to access, while exporting anything older to an external system. Know that the cost of keeping data on box is higher than storing it. The good news is, the cost of storage continues to decrease as technology advances. According to a March 2017 article published by Computerworld, “in 1967, a 1-megabyte hard drive would have set you back by $1 million. Today, that same megabyte of capacity on a hard disk drive (HDD) costs about two cents.” The specific amount of time before you export data to an external storage system will be based on your SOC’s business objectives. The bad news is, more devices are generating larger amounts of data. increasing the need for more storage. The growth of IoT is causing a major impact on networks. including increasing EPS. Also, different storage options have different costs. Flash memory has a higher cost than magnetic tape or optical discs; however, flash may be worth the higher cost because it performs quicker and can provide stored data faster when requesting it.