John Roese’s Blog CTO, Nortel

Security built in, not bolted on

Location: Flying over Atlantic Ocean, Amsterdam to Boston

Am flying back from a week’s vacation in Europe with family and friends. While sorting through a huge number of emails I have neglected (or ignored) while on vacation, I ran across a note from the leader of my Security research and architecture team at Nortel. He forwarded me an article from CNET that references a recent talk by industry security guru Bruce Schneier, who laments the very existence of the security industry, pointing out that our need to layer security products on top of various core transport, compute and productivity devices and applications is a clear indictment that those very entities are insecure and incomplete.

Reading this article struck me as a bit of déjà vu because prior to joining Nortel and Broadcom, I spent over 10 years of my career developing systems and technology that brought security into the very essence of communications transport. We, as an industry, tend to forget that the best networks and applications provide their core services in a way that fosters a high level of use but that also acknowledges that with that use comes inevitable abuse by people who are either malicious or just simply opportunistic.

If we think about the communications systems of the IBM SNA or Digital VAX era, what we had were very mature, complete systems that were able to deliver technology in context to the risks of their small controlled world. When the industry transformed to the Ethernet and PC era in the early 1990’s, we forgot about the kind of control the mainframe era had and, as a result, lost most elements of security and predictability. We did not particularly care, however, because there were no real defined threats at that time.

But, by the late 1990’s, into the early 2000’s, we found that we had become so dependent on these fantastic networks and internetworks, which were the source of huge productivity gains, that when the inevitable happened, and mass attacks on that infrastructure emerged, we were stunned and forced to evolve. With CodeRed, Nimda, the Love Bug and a host of other Internet and email worms and viruses, we realized that the nice simple, high-performance, global Internet was so unintelligent that it could barely detect, much less defend, itself from these attacks. From 2000 through to today we refocused, as an industry, on security in any form that would protect us.

So, here we are at the edge of a new era, one driven by hyperconnectivity. An era that will provide connectivity to a more diverse set of devices than ever before, one that will ingrain communications into every aspect of our lives and the systems we interact with.

The challenge that we face, though, is that, much as Bruce points out, the bolted-on security of our systems is a drag on their effectiveness and a mask over their true issue - the lack of strong inherent security capability. The technologies and systems that make up the next era of communications and IT must not forget the lesson of the past: that great networks must defend themselves because they will inevitably be the target of misuse, simply because they are great networks.

Looking at some of the technologies that we see as key to this future and their security posture, there seems to be some hope that we are starting from a stronger position. It is entirely possible, however, that the industry, much as it has done before, will be swept up in the rush to connect everything and to drive down cost that we will forget that the integrity of that system is an inherent requirement that cannot be compromised, ever.

As an example, in the 4G wireless dialog, there are a few technologies in the radio access network space. These include IEEE 802.16e Mobile WiMAX, 3GPP LTE, and 3GPP2 UMB (or CDMA RevC). Most of the debate in the industry is centered on which of these radio networks is the “right choice,” and far too little dialog is being focused on the other characteristics of the technologies. For those of you familiar with WiMAX or LTE, or even GSM or UMTS, ask yourselves the following questions. Do you understand the security model of each? Do you understand if it is strong or weak? Do you understand what assumptions were made about the system and how it will behave from a security perspective? Do you understand the cost of the security model used and its impact as overhead?

I don’t ask these questions for any other reason than to point out that it is easy to get caught up in transport technology or “speeds and feeds” and ignore the other aspects of a well-rounded communications system, which would result in an inevitable pattern of repeating our past mistakes. One of the reasons I feel that WiMAX 802.16e (not just the RF part but the whole system) has a strong possibility of playing a major role in the 4G hyperconnected future is that in addition to being a high-performance, low-cost broadband transport system, it leverages the IEEE security learnings (specifically the trials and errors of the Wi-Fi world) to deliver a system that makes few assumptions about the end systems’ security, but realizes that it must control access, protect transport and remain resilient even in the presence of the unknown.

We are also trying to make sure that the other 4G technologies, like LTE, take into account the hyper-connected world and its inevitable diversity and scale, and that security is architected in from the beginning. We shall see if we are smarter as an industry this time around and if we ultimately build the systems of the next generation to not only connect things but to also protect them with embedded security capability. This will simplify the system by eliminating the bolted-on security of past systems and maybe even achieve the end state that Bruce describes (or get us closer to it).

Let’s hope that one of the characteristics of 4G is that, from its inception, it’s a “Secure Network”.

Trackbacks/Pings

  1. […] While I have a number of topics in the queue, I wanted to take a run today at a few of the comments and questions that emerged from my Security post. […]

Comments

  1. John,

    I agree that security should be (mostly) a low layer consideration and that solutions beyond ipsec tunnels need to be arranged (ipsec bypasses packet QoS) for example)

    What beyond extension headers 50 & 51 (ipsec on ipv6) would you suggest?

    As an addendum to my question, where would you put security to insure payload integrity? Or do you see that as a different issue? (e.g. ipsec punches holes in firewalls, and there is no guarantee that the payload is not malicious)

    I might argue that WiMax and 4g is likely to be *less* secure as iuCs, iuPs and Iur traffic moves off of ATM transport that 3g release 4&5 provides without some sort of QoS sensitive security a the transport layer?

  2. Actually, the thing I think is MOST forgotten is that the threat models are fundamentally different from those in the past scenarios you cite. It is far too easy to focus on security models that don’t even begin to address current threat models! Improving transport security might not do much to improve things.

    For example, in the recent TJX fiasco the beginning of the attack came from an unsecured wireless deployment, but the real damage resulted because the back-end security systems didn’t protect against the threat model. Once a password was stolen via wi-fi eavesdropping, the whole ship was lost.

    All widely-deployed computer systems assume that any software an authenticated user runs should have access to pretty much anything the user has access to, like confidential files and the network. This is a bad assumption. If a password is stolen, or a orginally benign program gets infected with malware, confidential data can get shipped out onto the internet just as fast as you can say BigBaaadBob’s your uncle.

    Today’s systems must be designed to be secure even when the software isn’t trusted and authenticated users are not very trusted. Consider web browsers: they executed untrusted code every time they load a new web page. Providing security in this environment is a tough challenge.

    One interesting swing at this problem is the security system devised for the XO (the OLPC laptop) called Bitfrost. It is designed to protect against a series of modern threats in an environment where there is no substantial IT support (virus scanning, help desks, etc), and where the systems are operated by children as young as five.

  3. Note to poster above: As a general rule, IPSec should not poking holes through corporate firewalls to allow blind traversal of unknown payload. In fact, most enterprise-class IPSec/Firewall combination solutions have the capability to decrypt the payload at the point of entry so that the content can then be inspected at L2-L7 to ensure compliance. On a slightly different note, moving to an SSL VPN or using SSL offload can offer the same technology to deliver insight to the payload; but with much improved mobility and platform independence.

    As for marking and honoring QoS of IPSec encrypted sessions, this can be accomplished in many ways. One example of this is to use DSCP to 802.1p mappings. Differentiated Services Code Point (DSCP) uses six bits of the DS field to select the Per Hop Behavior (PHB) a packet experiences at each node. DSCP identifies the priority of service a packet receives in the network. When a packet is transmitted, the DSCP value of the inner header is then copied to the outer IP header, which is in clear text for the device to use for prioritization.

    Support for DSCP to 802.1p mapping allows the VPN devices to tag frames for prioritization over public and private physical interfaces. We should note that the 802.1p tag often does not remain with the packet as it travels from source to destination. However, the DSCP marker in an IP header does remain with the packet. Therefore, when a packet enters a layer 3 device, an 802.1p to DSCP mapping can also be performed (reverse from above) for proper QoS honoring.

  4. It is difficult for me to understand how we can avoid the “bolted on” security systems that Bruce mentions. As security must necessarily be very tightly linked to authentication of the communicating entities at both ends of a connection the associated security measures (encryption, protection, authentication, authorization, filtering) must therefore be end to end. The transport network should be concerned with connectivity, Quality of Service and protecting the integrity of the network itself (as opposed to trying to protect the endpoints: users, devices and applications) - but maybe that is exactly what you refer to as “network security”: Ensuring the network remains available with acceptable QoS ?

  5. Security and network stability also depends on the kind of network we are talking about. Example: A simple ping is enough today to keep the radio connection to a mobile terminal established all the time. What sounds like not much of a threat becomes quite big if you consider that this simple ping will empty mobile device batteries in no time. It’s not the amount of data that drains the battery but the radio connection that can’t go back to idle state. No problem for a fixed line network, big impact on wireless networks. Maybe not a widespread problem today while wireless devices are only temporarily connected to the network. In the future however it remains to be seen how to defend the network and the terminals against such simple things. Sure, simple NAT’ing at the network gateway helps but that’s not really how it’s supposed to be.

    The scenario is not even far fetched, it’s already happening today. Not with pings but with lost file sharing connections that are picked up by the next owner of the IP address:

    http://mobilesociety.typepad.com/mobile_life/2007/05/how_file_sharin.html

    Looking forward to meeting you at the Nortel Tech Conference next month,
    Martin

  6. KC, Thank you for the response.

    Unfortunately, as a general rule ipsec deployments do poke holes in firewalls. Decryption of every packet is not feasible from a performance/cost perspective.

    I am familiar with DiffServ. In fact I remember it from a previous incarnation as autovon precedence.

    I understand there are problems with udp encapsulation of ipsec packets (not tried it myself) including overly complex policy routing, throughput and other PitA hard to maintain machinations. Do you know more about this approach?

    My understanding of mapping to P and/or Q bits is that granularity is lost and again, there are (were?) performance issues. I don’t believe cisco supports this in earlier releases (might now) so anytime you traverse one of their routers with and older version of IOS—-kerplunk.

    Anyway, what you suggest is doable in a single vendor network or a lab (I guess), but IMO is not real world.

    To me, what is still missing at L2 is a universally supported and reliable authentication mechanism (perhaps added to the arp?).

    I think Martin’s comment is very interesting. To me it points out yet another compelling argument for ipv6.

    Comment?

  7. To me the whole idea of bolt on anything suggests that something was missed that should have been there in the first place. To me the whole security issue needs to address the regular user, who in most cases are not aware of what security means other than having their Norton interupt what they are doing to upload another definition file.

    I just want a device that has it’s security built in and is able to adapt to changing threats. I don’t want to have to remember to download security options, I don’t want to have to worry about buying the lasted version of security software, I don’t want to hear another IT guy tell me to turn off my security to allow an application to run, and I don’t want to remember 15 different passwords.

    To me security has to be built into the devices we use and those devices must be able to adapt to change. The networks need to recognize the devices and allow access depending on who happens to be using that device.

    I understand the need to discuss the P and Q bits, but as a regular user and purchaser of devices I need to know that the manufacturer that is creating these devices that I need to run a business is building security in. Last thing I need is to pay staff to study which security software works best or which security software will not cause problems with other areas of my business.

    John… you seem to have the right idea.

  8. Funny you mention Digital’s VAX. The VMS operating system lives on, and still the industry leader in security. VMS has been renamed OpenVMS, and is now available on the Alpha and Itanium processors. 29 years and still secure!

    Check out http://www.hp.com/go/vms

  9. I couldn’t understand some parts of this article Security built in, not bolted on, but I guess I just need to check some more resources regarding this, because it sounds interesting.

Leave a Reply