Originally posted on February 24, 2018 at medium.com
In cyber security you can’t throw a rock without hearing a sales engineer mutter something about their platform and how, when fully implemented, leads to a state of total Nirvana with unicorns, puppies, and absolutely no bad guys doing bad things. This isn’t a gripe about platforms. Honestly they are really useful because properly implemented tools that are designed to work together can do great things. Platforms can reduce engineering overhead and simplify how business units view a security posture. Trust me… It’s much easier to get an additional feature through a license purchase than through an acquisition of new software / hardware.
The platforms are normally born out of core technologies from the specific vendor. These are the corner stone products from which you build your platform from. Take Palo Alto Networks for example. Their core technology revolves around firewalls. However firewalls are just a part of their overall strategy. Hey you gotta start somewhere right? Well this entry point actually has a big effect on how Information Technology handles the management of these tools and how the platform may expand into other areas of the business. My experience here is mostly with Palo Alto Networks, but you can see how some of these lessons apply to other vendors.
Who Owns the Firewalls?
Nearly every organization on the planet starts out with a network team before a security team. The network team operates at a layer below everyone else. They are responsible for the literal transmission of information between two points. Their work is incredibly important so it makes sense that their teams got stood up first. Firewalls as well are not new concepts. Firewalls have been around forever and have been a critical part of network architectures. Firewalls began their lives as network devices, same as routers and switches.
Legacy deployments featured a much more static firewall policy set that was chaotic but still maintainable by a small, likely overworked, team. Anymore firewalls policies are ever changing as new systems or websites come online. This is quite the burden for a team normally responsible for routing, switching, and ensuring the general availability of communication paths. It’s a tall task to carry the entire weight of communication infrastructure as well as being nimble enough to respond to the ever changing needs of the business. There are tools out there to help with stream lining policy changes, but that’s just another layer on top of a busy platform. And as if that was not enough now add on intrusion detection, binary detonation, virtual private networks, network anti-virus, etc.
Well the Intrusion Detection / Prevention Systems are typically security oriented products as the skills required to manage such implementations are vastly different than the skills needed to manage a network. Binary detonation, in this example I’m talking about Wildfire ®, involves actual malware… definitely not something you want to put upon your network team if you have a group of qualified cyber security professionals at your disposal. All of these services are located within the firewall. So is the firewall still a network device or are we seeing that platforms are likely far too complicated to be managed by a single team.
The Instinct to Silo
The siloing of system administration is a long time-honored tradition of Information Technology. “I can’t trust you not to break it”. We have all heard this uttered from a person whose job probably does rely upon the uptime of the system involved. Yet, it is the siloing of responsibilities that makes deploying platforms either a dangerous or wasteful exercise for most organizations. Dangerous because silos lead to a knowledge gaps that expose organizations to the “hit by the bus” syndrome. What happens when our hot shot engineer gets that better offer and jets? Coming back from that is a long and difficult journey.
How about wasteful? I think it’s fair to say that platforms can be expensive endeavors. When your approach to firewalls is to just do firewall stuff you will miss out on the added benefits and capabilities. I’ve seen this a lot especially with “next-gen firewalls”. You can always tell which team deployed the firewalls by how the rules are setup. If you see a firewall with only IP address and port information with no corresponding application identifier or user identifier you’re likely looking at a shop that migrated from legacy firewalls that lacked the newer features. There could be all sorts of reasons why the rules hadn’t been converted to use the enhanced capabilities, but what it really boils down to is that these newer features are outside of the common understanding of what firewalls do from a networking perspective. TCP/IP is based on port and IP so that is what is needed to ensure communications.
Security professionals sometimes forget perspective and need to remember that different teams have different values and objectives
This is not an attempt to smear the good folks in the networking world. Quite the contrary. Security professionals sometimes forget perspective and need to remember that different teams have different values and objectives. If you’re talking to a team that has been around for some time and haven’t experienced a security breach or some other network security catastrophe what right do you have to say that their work isn’t good enough? In the end though you’re still paying for the next gen features and if you’re not using them it probably constitutes a waste of money.
Sharing the Burden
Each organization is going to be different with how you break up the responsibilities within a platform. There are some conversations
- Identifying a group of people responsible for the overall function of the platform. This helps clear the way for platform upgrades or the introduction of new features.
- Establish a business owner or committee to help break technical deadlock. Believe it or not when you have teams with different priorities working within the same platform you’re bound to have conflict. The issue with platforms is that neither side is 100% right or wrong in their view of how to best utilize a tool. An outside group needs to be able hear the technical perspectives and help direct the overall platform functions to align with business initiatives.
- The business owner or committee is also responsible for establishing and enforcing governance over how you deploy, operationally manage, and distribute roles / permissions across the platform.
- Platforms with robust Role Based Access Control can help distribute the access needed to perform the different tasks within the platform without giving more access.
- A consideration you need to make when selecting or distributing platform work is to understand how the various roles can impact each other. Mapping out these interactions ahead of time can help with role development and troubleshooting.
- Beyond reducing the workload for a single individual or team responsibility sharing makes people feel more involved and spreads the feeling of ownership which leads to greater platform satisfaction.
An experience I have had in this space is managing Palo Alto Networks firewalls. I was part of a maturing organization that was doing a ton of great work in the network security space. Initially the firewalls were totally managed by the Information Security Program. This worked out great at first as the deployment was fairly simple and straight forward, but over time problems began to develop because the complexity of the platform began to outpace what the single team was able to support. What we realized was that a single team was providing all the lift and other capable teams were on the outside looking in. Our solution was to distribute work by the tabs in the management dashboard.
We broke down the roles by tabs. The breakdown went as such:
- Dashboard — Shared by all. Users could customize their own dashboard
- ACC — Shared by all. This is a reporting interface and provides contextual traffic information
- Monitor — Read Only by all. Our view was if you had login rights to the firewall admin interface you should be able to see what types of traffic the firewall was handling
- Policies — Read Only by all. Administered by the Security Team. The thought went that modern firewall policies are far more than port and IP and that app-id, user-id, IDS/IPS profiles, etc were best administered by the Security Team. The Network Team needed to see all the policies that were in play to understand traffic flows.
- Objects — Admin by all. Each admin team had the ability to create / alter objects. Robust logging and alerting helped provide the governance needed to share this access.
- Network — Read Only by all. Administered by the Network Team. The network tab is where the interfaces are configured, virtual routers are managed, VPN… You know, all the good networking stuff. The Security Team needs to be able to view the configuration of the network but lacked the need to be able to alter the settings.
- Device — Administered by all. The device tab is the main hardware administration panel. This is shared tab between the Security and Network teams and follows the governance provisions set forth by the “business owners” which was a collection of the CISO and the team managers from both Network and Security. The ultimate business manager was the CISO and that was a decision from other executive managers. The firewalls were viewed as security devices and thus assigned to the CISO.
At some point your organization is going to have to define the platforms as fitting a core need and allowing responsibility of the platforms to trickle down from there.
Platforms, or really any enterprise wide tool, requires a collection of different technical disciplines to provide the level of support needed. There is no right way as long as a clearly communicated plan exists for managing these complex tools. By sharing responsibilities you will find that the capabilities of these platforms will begin to live up to their billing.