This is part 2 in a series. Click here for part 1, or submit edits directly via GitHub.

The Pragmatic Process

As mentioned in the previous section, this process is designed primarily for more complex networks, and takes into account real-life organizational and technological complexities.

Here is the outline, followed by the details:

  1. Know your network.
  2. Know your assets.
  3. Know your security.
  4. Map the topology.
  5. Prioritize and fix.
  6. Monitor continuously.
  7. Manage change and build workflows.

The first five steps establish the baseline, and the next two manage the program, although you will need to periodically revisit previous steps to ensure your program stays up to date as the business evolves and risks change.

Know Your Network

You can’t secure what you don’t know, but effectively mapping a network topology – especially for a large network – can be daunting. Many organizations believe they have accurate network topologies, but they are rarely correct or complete – for all the reasons in the previous section. The most common problem is simply failure to keep up-to-date. Topology maps are produced occasionally as needed for audits or projects, but rarely maintained.

The first step is to work with Network Operations to see what they have and how current it is. Aside from being politically correct, there is also no reason not to leverage what is already available. Position it as “We need to make sure we have our security in the right places,” rather than “We don’t trust you.” Once you get their data, evaluate it and decide how much you need to validate or extend it.

There are a few ways to validate your network topology, and you should rely on automation when possible. Even if your network operations team provides a map or CMDB, you need to verify that it is current and accurate. One issue we see at times is that security uses a different toolset than network operations.

Security scanners use a variety of techniques to probe the network and discover its structure, but standard security scanners (including vulnerability assessment tools) aren’t necessarily well suited to building out a complete network map.

Network operations teams have their own mapping tools, some of which use similar scanning techniques, but add in routing and other analyses that rely on management-level access to the routers and network infrastructure. These tools tend to rely more on trusting the information provided to them and don’t probe as heavily as security tools. They also aren’t generally run organization-wide on a continuous basis, but are instead used as needed for problem-solving and planning.

Know Your Assets

Once you have a picture of the network you start evaluating the assets on it: servers, endpoints, and other hardware. Security tends to have better tools and experiences for scanning and analyzing assets than underlying network structure, especially for workstations.

Depending on how mature you are at this point, either prioritize your scanning to particular network segments or use the information from the network map to target weak spots in your analysis. Endpoint tools such as configuration/patch management or endpoint protection platforms offer some information, but you also need to integrate a security scan (perhaps a vulnerability assessment) to identify problems.

As before, this really needs to be a continuous process using automated tools. You also need a sense of the importance of the assets, especially in data centers, so you can prioritize defenses. This is a tough one, so make your best guesses if you have to – it doesn’t need to be perfect.

Know Your Security

You need to collect detailed information on three major pieces of network security:

  • Base infrastructure security. This includes standard perimeter security, and anything you have deployed internally to enforce any kind of compartmentalization or detection. Think firewalls (including NGFW), intrusion detection, intrusion prevention, network forensics, Netflow feeds to your SIEM, and similar. Things designed primarily to protect the core network layer. Even network access control, for both of you using it.
  • Extended security tools. These are designed to protect particular applications and activities, such as your secure mail gateway, web filter, web application firewalls, DLP, and other “layer 7” tools.
  • Remote access. Security tends to be tightly integrated into VPNs and other remote access gateways. These aren’t always managed by security, but unlike network routers they have internal security settings that affect network access.

For each component collect location and configuration. You don’t need all the deep particulars of a WAF or DLP (beyond what they are positioned to protect), but you certainly need complete details of base infrastructure tools. Yes, that means every firewall rule. Also determine how you manage and maintain each of those tools. Who is responsible? How do they manage it? What are the policies?

Map the Topology

This is the key step where you align your network topology, assets (focusing on bulk and critical analysis, not every single workstation), and existing security controls. There are two kinds of analysis to then perform:

  • A management analysis to determine who manages all the security and network assets, and how. Who keeps firewall X up and running? How? Using which tool? Who manages the network hardware that controls the routing that firewall X is responsible for? Do you feed netflow data from this segment to the SIEM? IDS alerts? The objective is to understand the technical underpinnings of your network security management, and the meatspace mapping for who is responsible.
  • A controls analysis to ensure the right tools are in the right places with the right configurations. Again, you probably want to prioritize this by assets. Do you use application-aware firewalls (NGFW) where you need them? Are firewalls configured correctly for the underlying network topology? Do you segment internal networks? Capture network traffic for detecting attacks in the right places? Are there network segments or locations that lack security controls because you didn’t know about them? Is that database really safe behind a firewall, is or it totally unprotected if a user clicks the wrong link in a phishing email?

The first analysis focuses on implementation of management processes and workflow. Sure, everyone has policies, but how are the actual infrastructure and defenses managed? Who is responsible for what and where does the data flow? The second analysis is all about preventing and detecting attacks and aligning controls. Are the right defenses configured properly in front of the right assets?

Once you map the assets to the network topology, to the security defenses, to the management infrastructure, two pictures emerge – how your defenses are really aligned and how you manage them.

Prioritize and Fix

By now you have a deep understanding of your network topology, a decent understanding of where important things are on the network, and a solid idea of how your security is configured around and within it. Now it is time to start fixing things. And remember, we are focusing on network security today, not the endless list of other controls you can bring to the table. Your goal is to improve how you manage your security over time, not just plug a few holes until you need to start all over again.

This involves:

  • Repositioning network security tools. Ensure you have the correct preventative or monitoring control in the right physical location. This isn’t about buying new things, but understanding and best using the ones at your disposal.
  • Reconfiguring network security tools. Adjust rules and configurations to provide the desired protection.
  • Consolidating network security management so you can maintain visibility and implement changes more efficiently in the future.
  • Position new tools as needed. You may already be using application-aware network security, egress monitoring, command and control monitoring, DDoS protection, cloud web filtering, and malware gateways. But if not you now have much better information for integrating them effectively into your program, and positioning and configuring them.

Right now we are still in the “initial fix” phase. In a moment we will discuss the continuous change management phase, where you focus on ensuring things never get so out of sync again. Most organizations fix some immediate things while they begin adjusting their management processes and workflow. There is no reason you have to hop through these steps one at a time.

Continuously Monitor

This phase is they key to not needing to start all over again in a year, after everything gets out of sync again. We have moved past baselining into managing the program. There are four key pieces to keep track of:

  1. Network topology changes. Sometimes these are small changes such as a new routing rule, while other times it might be addition of an entire new large network due to an acquisition. Security can monitor for these themselves or establish stronger collaborative workflows with network operations. Regardless, topology needs to be revalidated periodically to catch errors and omissions. You can use the same tools you used to build and validate your initial topology map, but now on a continuous or periodic basis, in addition to passive network monitoring tools that track live traffic.
  2. Asset changes. If your servers, workstations, and other IT assets aren’t moving around on pretty much a daily basis, odds are you are out of business. Security scanners, especially vulnerability scanners, are your tool of choice here.
  3. Network security tool changes, including both uses and configurations, which is why we emphasized consolidating network security management infrastructure.

You will notice we skipped the part about monitoring for bad guys. That’s because this report is focused on managing your overall program, not the details of daily defenses and incident response. It goes without saying, but we’ll say anyway, that continuous security monitoring also includes extensive monitoring of network activity. That’s why we spend so much time determining the best places to monitor and defend, and the best tools and configurations for the job.

The last piece of this phase is creating reports for auditors and executives. This is essential to meet compliance obligations and demonstrate your value to the rest of the organization. Ideally you can quickly create these reports without undue effort because you already have all the required data, constantly updated and accessible.

Manage Change and Build Workflows

This is the most important phase of the entire process. Until now you have mostly focused on understanding your infrastructure and developing the security controls around it. But this is impossible to maintain unless security works more closely with both IT operations and various business units. The key is not only to refine internal processes, but to create minimal-friction workflows for working with the rest of the organization. The easier it is for them to go through an approved process, the less likely they are to try and circumvent it.

And the more you can automate this, including ongoing data gathering to detect the details and implications of changes, the better.

In this section we will cover the security change management process, and in the next section we will offer examples of common workflows for coordinating with other areas. For detailed processes for network security operations, we recommend our own Network Security Operations Quant Report.

  • Trigger: A change can be a formal request from the outside, internal updates, or a change in the operating environment (such as a routing change detected by security, which didn’t go through a change request process). Ideally everything runs through the approval process, but even the best-run organizations need to deal with out-of-process changes they detect.
  • Process change request and authorize: Examine the unapproved change to determine the security response, or process the internal or external change request. Determine the requirements, impact, security risks, and priority, then slot the change into a maintenance window. Priority reflects both business and security needs, especially when threats are a factor.
  • Test and approve: This step includes development of test criteria, any required testing, result analysis, and approval of the signature or rule change for release once it satisfies requirements.
  • Deploy and confirm: Deploy and verify that changes were successful, including both installation and operation. This might include use of vulnerability assessment tools or application test scripts to ensure there is no disruption of production systems or attack surface added as a result of the change.
  • Audit/validate: The full process of making a change encompasses more than merely having the operations team confirm it during the Deploy step – another entity (internal or external, but not part of the ops team) should audit it as well to provide separation of duties. This entails validating the change to ensure policies were properly updated and matching it against a specific request. This closes the loop to make sure there is documentation (and an audit trail) for every change.
  • Emergency updates: In some cases, including data breach lockdowns and imminent or active zero-day attacks, a change to the network security device’s configuration must be made immediately. An ‘express’ process should be established and documented in advance as an alternative to the normal full change process, ensuring authorized approval for emergency changes, as well as a rollback capability in case of unintended consequences.