Is Enterprise Security ready for the 'flat network'?

Walking around the show floor here at HP Discover (follow the show on Twitter using the hashtag #HPDiscover) I ran into one of our guest bloggers whose off-hand comment on security inspired this post. He's not a security guy, but an IT generalist and analyst - and he mentioned that the network of the imminent future is a flat, layer 2 network. My response, naturally as someone who's grown up largely in the enterprise world, was "...but Enterprise Security paradigms aren't designed for 'flat' networks, security is made up largely of segmented, segregated pieces" to which Joe said ... "Well you've got to get over that, then".


I've been thinking about that statement for the past 3 hours as I listened to the keynotes from Meg Whitman, Dave Donatelli and George Kadifa and it's still eating at me. Enterprise security for the last 15 years has largely been a block-and-tackle sort of endeavor where applications were built without security in mind so the security team would build the security perimeters and measures 'around the things'. This just won't fly anymore... and honestly it's been in this state for at least a year or more...


I don't think I need to harp on why I think enterprises aren't ready for flat network models, I think that's pretty evident by now and I hope if you're reading this post you "get it" ... if not I'll explain if necessary. On with it then, we have a problem, clearly, so what of it?


Let's talk about what enterprises can do to not fall into utter chaos once the flat, layer 2 network starts to become a reality to more than just your cloud. Let's talk about what happens when the flat network becomes a reality in your data center and 'office' compute perimeter. In our closing video here on Day 1 one of our enterprise customers agreed this reality is already starting to pop up in their org as well...



Rethinking the enterprise network


What happens when there is no physical cable that goes between server A in "finance" and server B in "R&D"? I'll tell you what - many of the security teams out there become very confused about how they're going to keep the 'bad things' that could happen to the R&D server out of the finance environment. Where we used to use firewalls and network-level counter-measures that would allow you to say things like "that application is only accessible by 10 people in finance, they're on their own network" we now have "that server (or more likely service, but I won't go there now) is accessible to anyone on the network." This may scare you a good bit...and it should.


Rather than thinking that the servers in Rack 1 can't ever mingle with the "Internet accessible servers" in Rack 2 - because there is no way to physically go between them without crossing the firewall, and you have ACLs for that - you need to start thinking that everything is connected to everything else, everything is out in hostile space, and you need to start designing accordingly. This generally requires the intelligent application of security measures before the product or service/application is finished so as to use the old and tired phrase "bake security in, rather than bolt it on."


Now I don't want to discount the capabilities of virtualization to allow you to continue to virtually shim in that security filtering counter-measure. While there are fantastic developments and innovations that allow us to keep clinging to the old "security-after-the-fact" and "outside-the-thing" ways, it's a bad idea and we now have a chance to say "No more, let's do it right" should we choose to accept it. This revolution in thinking forces security organizations to go forth and sow their message into the enterprise, which arguably we've been miserable failures at for a long, long time ... on the whole. Let's face it, while some organizations "find religion" after the massive data breach hits the front page - a lot of you out there are secretly hoping your organization gets popped for no other reason than your CIO will finally start to fund security.



A liberating feeling of acceptance


This all sounds scary if you're a CISO, and it is likely worse if you've never thought this way before - but once you've gotten over the initial shock and moved on to acceptance it's actually quite the liberating feeling, really. 
Look, the flat network is coming, and you may as well get over it and live with it. As the CISO it's just easier to embrace that fact than to fight it, but you (I mean you the CISO) can't actually fix this problem on your own. When the flat network comes, you're going to need to make sure that you talk with the rest of the IT stakeholders to get the strategy right. "Bolting security on" just isn't going to work.
Unfortunately, this isn't going to be an overnight transformation process, you're not going to come to work tomorrow with the network magically ready for a flat network model - this is something you're going to have to learn to architect for. There are a few key things you're going to need to do before then:
  1. Assume applications will be in hostile space - make sure you've instilled it in every developer and project manager's head that every app they build may and likely will end up in hostile network space. This lets you look forward from the way things are today (we're lying to ourselves about "internal stuff") to the way things will be in the near future.
  2. Focus on software security - Assume that there will be no firewall between your application and the hostile network known as the Internet, seriously. There is no more "internal network" that you have grown to depend on ... it's all hostile address space. Every application needs to be software security checked to the 9's, making the assumption that if there are any vulnerabilities there is nothing keeping outside attackers from hitting any application.
  3. Manage & understand your users - You can't assume only legitimate users will use your application, or have access to the interface. This means you can't assume only company employees, or 'legal employees' will have access to that app ...what if everyone had access to it? Could your applications behave accordingly if everyone could bang up against it all day, every day? You need to focus on identity and access management heavily - rather than relying on the firewall to keep non-legal users out.


The flat network is coming, and I've seen the hardware to prove it ... so is the security team ready? The likely answer today is "no" ... but we can do things to make sure the answer gets better as we better understand that there is no such thing as "internal" applications and services anymore - it's all deployed anywhere, any time and to any users - and it needs to stand up and defend itself. It's not a trivial challenge...

stantosc(anon) | ‎12-09-2012 11:55 PM

Well you asked for a response, so here it is. :)


You touched on a lot of points, making some inferences and conclusions in the process.  I'll summarize what stood out and add some of my thoughts.


"the network of the imminent future is a flat, layer 2 network"

"..what happens when the flat network becomes a reality in your data center and 'office' compute perimeter"


I think these comments are actually talking about eliminating network policy enforcement, which often happens on Layer 3 gateway devices.  Increase in Layer 2 networking is a very valid transition occuring now in the Data Center space, mostly driven by virtual workload mobility.  IPv6 will allow for very large Layer 2 domains.  But for performance and management reasons, the entire Enterprise will not be eliminating Layer 3 gateways any time soon.


"... capabilities of virtualization to allow you to continue to virtually shim in that security filtering ... it's a bad idea and we now have a chance to say "No more, let's do it right""


The conclusion you seem to be drawing here is that virtlalized implementations of network security policy enforcement are a bad idea.  Not sure if there's a specific technology you're thinking of here or whether it's in the context of virtualized Layer 2 policy enforcement (the future?) or Layer 3 policy enforcement (status quo).  Either way it sounds like you don't think they will work.


"a few key things you're going to need to do.. Assume applications will be in hostile space.. Focus on software security.. Manage & understand your users"


So the conclusion is that we can forego network-level security policy enforcement and shift the control to the application layer with proper secure development practices and Identity and Access Management.  This might work.. for new applications (and ongoing dev of existing platforms that don't need to be re-architected to support "enhanced security" / IAM).


So what the heck is Raf really saying here?  If I might summarize:

  • Cloud-based apps are location-agnostic; you won't have a "place" in the network to perform network-based policy enforcement because the workload might move to a different Data Center or even a different provider
  • Users can be "anywhere", hence no way to support IP-based policy definition
  • Services will be exposed for arbitrary consumption by other applications, hence source/destination-based policy enforcement is not feasible
  • Enterprises are now hostile; "Trusted" corporate users coexist with contractors, vendors, suppliers, partners, customers, and visitors.. not to mention your WAN is probably extended into countries whose government agents may be trying to subvert you.
  • Without knowing who to trust, where the users are, where the applications are, or IP addresses associated with any of the above, you can't do effective network-level policy enforcement


"Don't believe the hype"


Network-level policy enforcement isn't going anywhere.  It will evolve, but it isn't dead.


There is one concept that I will agree with in your blog post, which is that a highly granular, IP-based policy is very difficult to enforce in today's Data Center, for the reasons cited above.


However, the concept of shifting layers of control from the network to the application is as absurd as I've ever heard.  


First from a maturity perspective, this makes no sense.  Network guys understand firewall policy, they know their network topologies, and they know what they can and cannot control within a protocol.  App guys are not at all interested in enforcing policy.   However, assuming that you have an IAM foundation that aligns with your data governance policy (!), this could be as easy as a web module bolt-on (i.e. Oracle Access Manager) or as complex as baking it into the application logic.  The reality though is that even in 2012, devs have a really hard time getting app sec right.  This is compounded by legacy or COTS platforms where you can't implement your IAM or you can't rearchitect for proper data-level control.  Exposing these platforms to the Internet at large is just asking for trouble.


Second, exposing apps and data to customers/partners/suppliers/etc. is not equivalent to exposing them to the Internet.   Even the largest enterprises, using RFC1918 and many /16s or /8s don't even come close to the 3.7 billion public IPv4 hosts on the Internet.   For this reason, there's a valid case for maintaining the concept of "Enterprise" (or Internal) resources versus "Externalized" (or Internet-facing) resources.


So here is the common ground I think we stand on:

  • Hostile users are inside your perimeter
  • Data and systems are being Externalized which probably shouldn't be
  • Cost savings are driving the use of hybrid internal/external cloud technologies
  • Users bypass IT and use unauthorized external cloud services
  • The most effective way to minimize a threat is to reduce the sources of attack and to reduce the attack surface


So where will the future take us?


App security still matters. Yes, application security is a key piece in the security puzzle.  It is the most data-centric layer of control we have, and it isn't going anywhere.


Network security policy in the Enterprise Data Center will be disassociated from IP addresses.  Policy will be associated with virtualized services, which can migrate across virtual datacenters and workloads.  Much like LISP allows for the separation of routing from addressing, service-based policy enforcement will separate policy enforcement from addressing.


Identity will be embedded into the network layer.  Enabling network policy enforcement via Identity will be a key enabler to disassociate Enterprise user-based access policies from IP addressing.  The granularity of this policy enforcement could be extremely high or low depending on the type of authentication available and places in the network where traffic originates (Enterprise wireless, desktop, Data Center, Internet, etc.)


Internet-based cloud providers will leverage SDN to provide Enterprise-level capabilities.  This is the next logical evolution for cloud providers to make inroads in the Enterprise markets.  Policy enforcement, monitoring, network management integration, performance management and more will come.


Hybrid cloud use needs to be based on Internal or External-facing policy.  It's a cool idea to be able to shift workloads from your internal Data Center out to EC2, but just because you can doesn't mean you should.  If internal resources are only exposed to your Enterprise, then that should also be the case if the workload moves to another provider.  The only way to do that with externalized providers is with network-level policy enforcement.


Users will continue to do what's easiest for them.  Nothing's going to stop Johnny from uploading your SSNs to Dropbox in order to share with that Russian vendor.  You better hope he knows how to encrypt that file.  In the end, CIOs need to make their services as easy to consume as external providers if IT wants to keep their "job".



Hopefully I've made all the points I set out to make.. I have entirely too many things I want to say for a simple rebuttal. :)


BTW I lol'd at the "Blitzed Rafal" RT.. whoever did that


Leave a Comment

We encourage you to share your comments on this post. Comments are moderated and will be reviewed
and posted as promptly as possible during regular business hours

To ensure your comment is published, be sure to follow the Community Guidelines.

Be sure to enter a unique name. You can't reuse a name that's already in use.
Be sure to enter a unique email address. You can't reuse an email address that's already in use.
Type the characters you see in the picture above.Type the words you hear.
About the Author

Follow Us
Community Announcements
The opinions expressed above are the personal opinions of the authors, not of HP. By using this site, you accept the Terms of Use and Rules of Participation