As we wrap up our series on Fact-Based Network Security, let’s run through a simple scenario to illustrate the concepts. Remember, the idea is to figure out what on the list will provide the biggest impact for your organization, and then do it. We make trade-offs every day. Some things get done, others don’t. That’s the reality for everyone, so don’t feel bad that you can’t get everything done. Ever. But the difference between a successful security practitioner, and someone looking for a job, is that success is about consistently choosing the right things to get done.
Some folks intuitively know what’s important and seem to focus on those things. They exist – I’ve met them. They are rock stars, but when you try to analyze what they do, there isn’t really a pattern. They just know. Sorry, but you probably aren’t one of those folks. So you need a system – you know, a replicable process – to make those decisions. You may not have finely tuned intuition, but you can overcome that by consistently and somewhat ruthlessly getting the most important things done.
Scenario: WidgetCo and the Persistent Attacker
In our little story, you work for a manufacturer and your company makes widgets. They are valuable widgets, and represent intellectual property that most nations of the world (friend and foe alike) would love to get their hands on. So you know that your organization is a target.
Your management gets it – they have a well-segmented network, with firewalls blocking access to the perimeter and another series of enclaves protecting R&D and other sensitive areas. You have IPS on those sensitive segments, as well as some full packet capture gear. Yes, you have a SIEM as well, but you are revisiting that selection. That’s another story for another day.
Your users are reasonably sophisticated, but human. You run the security operations team, meaning that your folks do most of the management and configuration of security devices. Knowing that you are a target means you need to assume attackers have compromised your network. But your tight egress filtering hasn’t shown any significant exfiltration.
Your team’s task list seems infinite. There are a myriad of ports to open and close on the firewalls to support collaboration with specific business partners. Your company’s sales team needs access to a new logistical application so they can update customers on their shipments of widgets. And of course you are a large customer of a certain flavor of two-factor authentication token for all those reps.
Your boss lights up your phone almost daily because she gets a lot of pressure to support those business partners. Your VP of Engineering is doing some cool stuff with a pretty famous research institution in the Northeast. The sales guys are on-site and don’t know what to tell the customer. And your egress filters just blocked an outbound attempt coming from the finance network, maybe due to the 2FA breach. What do you do? No one likes to be told no, but you can’t get everything done. How do you choose?
Get back to the risks
If you think back to how we define risk, it’s pretty straightforward. Which assets are most important? Clearly it’s the R&D information, which you know is the target of persistent attackers. Sure, customer information is important (to them) and finance information would make some hedge fund manager another billion or two, but it would be bad if the designs for the next-generation widget ended up in the hands of a certain nation-state.
And when you think about the outcomes that are important to your business, protecting the company’s IP is the first and highest priority. It supports your billion-dollar valuation, and senior management doesn’t like to screw around with it. Thinking about the metrics that underlie various outcomes, you need to focus on indicators of compromise on those most sensitive networks. So gather configuration data and monitor the logs of those servers. Just to be sure (and to be ready if something goes south) you’ll also capture traffic on those networks, so you can React Faster and Better if and when an alert fires.
It’s also a good idea to pay attention to the network topology and monitor for potential exposures, usually opened by a faulty firewall change or some other change error. Your operational system gathers this data on an ongoing basis, so when alerts fire you can jump into action.
In our scenario, the R&D networks are most critical, pure and simple. So you task your operations team to provide access to the research institution as the top priority. Of course, not full unfettered access, but access to a new enclave where the researchers will collaborate. After your team makes the changes, you do a regression analysis, to make sure you didn’t open up any holes, using your network security configuration management tool. No alerts fired and the report came back clean. So you are done at that point, right?
We don’t think so. Given the importance of this network, you keep a subset of the ops team with their eyes on the monitors collecting server logs, IDS, and full packet capture data. You have also tightened the egress filters just in case. Sure some folks get grumpy when they are blocked, but you can’t take any chances. Without a baseline of the new traffic dynamics, and without a better feel for the log data, it’s hard to know what is normal and what could be a problem.
Admittedly this decision makes the VP of Sales unhappy because his folks can’t get access to the logistical information. They’re forced to have a support team in HQ pull a report and email it to the reps’ devices. It’s horribly inefficient, as the VP keeps telling you. But that’s not all. You also haven’t been able to fully investigate the potential issue on the financial network, although you did install a full packet capture device on that network to start grabbing the traffic.
How do you justify these trade-offs? With data, or the lack thereof. During your risk analysis process, everyone agreed how bad it would be for the R&D network to be compromised. You’ll need to remind the folks on the senior team because they will be squealing, and also that the potential for shenanigans when opening up even a portion of the network to a research institution must take priority.
To take the possible breach seriously, you should bring in a 3rd party forensics firm to do a quick investigation and analysis, because your team will be occupied for a couple days. This is to make sure there isn’t a fundamental and widespread breach in from the finance network. Sure, it costs (which makes your boss unhappy), but again you know that until you understand the impact of this R&D collaboration, it needs to take priority. Even if it means upsetting some other heavy hitters. Unless they want to change your priorities. But until you get different marching orders, you stay true to your plan.
Of course, if the forensics guys show that the data from the token vendor breach was used to gain a foothold in your finance department, you will redeploy some of your operations folks to do a more thorough investigation, knowing that would become the most clear and present danger. Note that we said some, not all, the ops folks. With your egress filters in place and full packet capture on the finance network (to facilitate the forensics investigation), you don’t think the damage is extensive.
You may be right. Or not.
Are these the right decisions? You won’t know for months if ever, and you are always open to second guessing because hindsight is 20/20. But you have used your organization’s priorities and operational data to prioritize decisions. Sometimes you’ll be right. Actually, we’d like to think most of the time you’ll be right. And you won’t be depending on intuition or faith.
But not always. As long as you can defend your decisions with data, and are consistent in how you decide on your priorities, your senior teams should support those decisions. Of course, that is a very idealistic position, and we get that. Even data will not stop you from being thrown out of the car at high speed when they need a fall guy (or gal). Unfortunately that goes with the territory.
Remember: no one is right all the time. That’s not a realistic definition of success. In our opinion, the goal is to be consistent and make fact-based decisions, based on operational data reflecting the priorities of your organization. In this series we believe we have outlined a process to achieve this consistency, and shown the importance of systematically collecting and analyzing operational data. At the end of the day, you can only affect the things within your control – of which how you allocate time for yourself and your team is an important lever – if not the most important lever. Because ultimately time is the only resource we can’t make more of.