How to Stop Talking About — and Start Fixing — Cyber Security Problems

 by Bill Hancock

Why are viruses so successful in killing systems? The answer is simple: operating systems do not protect themselves. I know this to be true. Many years ago, I was an OS developer at a very large computer company. I crafted a product that would check all programs, when they were asked to run, for anomalies and other infestations. To ensure a running system, applications were inoculated at system installation time before the system had a chance to be infected in any manner. In this way, a system “blueprint” of a clean system could be made, cryptographically stored, and used to control any malware introduced into the file system. If infested, the modified program was not allowed to run. Viruses disappeared from that OS, which is still in use today in large, complex computing environments where reliability is a major requirement. It’s funny how other vendors did not seem to learn that lesson.

As a security “graybeard,” I spend a great deal of time in meetings with companies, developers, government agencies, international consortia, and other assorted groups of people who continually want to do something about cyber security. Yet they never get to the heart of the problem: fixing the issues that cause the security problems to happen.

The problems we see in cyber security — breaches, viruses, worms, data theft, system corruption, network scanning, packet grabbing, and any number of related issues — are about to get much worse. This is mostly because we continue to deploy base technologies that were developed almost 30 years ago, when security was not an issue and we could trust that computers on a network would not try to subvert the operations of others on the network. We continue to write software with programming models of yore, and yet we do not instill good security programming principles (such as the Systems Security Engineering – Capability Maturity Model [SSE-CMM]) in those who write code. We continue to deploy systems and networks in insecure ways for the sake of getting things to market quicker and making money faster, at the risk of compromising customer privacy data and increasing the occurrence of identity theft. At the same time, we strive to make these flawed programming methods and insecure protocols and tools more easily available via wireless technologies to make network connectivity ubiquitous. We even extend them to areas where such technology has not previously been a factor: home appliances, automobiles — even clothing.

Consequently, we perpetuate the cycle of poor cyber security and, indeed, make the situation worse as we become more dependent on technological innovations that inherit technical security flaws from the underlying infrastructure and methods used to create them. We both need to create the security components we lack (e.g., cryptographic key management) and better apply the security components we have (e.g., installation of wireless security controls). Without some serious changes in the way we apply security science to the base technologies used to construct the technologies of the future, we are a long way from achieving cyber security.

CYBER SECURITY’S TRIPLE PLAY

So, what needs to be done? The technologies of the next 10 years are going to revolve around three basic areas: 

• 1. The TCP/IP protocol

• 2. Wireless communications methods

• 3. Identity management

Addressing these three basic areas will go a long way toward making real security possible and breaking the interminable cycle of doom-and-gloom meetings we all seem to be stuck in these days.

 
Fixing TCP/IP

TCP/IP is a formidable protocol and highly useful for base networking. The problem is that it never had any security methods built into it to ensure that even base security controls (authorized user access, protocol header verification controls, protocol filter lists, session verification, etc.) were included. As companies look to save money by merging data networking, video, and voice methods into more manageable network infrastructures, the push is on to replace traditional telco methods with TCP/IP networks. Unfortunately, TCP/IP networks do not have the luxury of being private in nature, like SS7, or singular in technical use, like a traditional videoconferencing network.

IP spoofing attacks are possible with TCP/IP because the protocol does not do source address cryptographic verification — an omission that allows DDoS spoofing attacks and all sorts of false address infiltration. Basic companion applications such as DHCP [Dynamic Host Configuration Protocol] and DNS [Domain Name Server] are sorely lacking in basic security controls, which prevent infiltration of the applications, improper modifications of application data pools and databases, and infiltration of the applications themselves (in which they may be co-opted to help in a cyber attack). The TCP/IP V6 (IPV6) protocol suite does not solve the problem, for a number of reasons:

• It has no strong source authentication.

• It continues to allow the use of many of the same companion protocols as IPV4. 

• It does not provide for fine-level controls over packets and transmissions to ensure that only authorized and properly identified packets are allowed on a network.

TCP/IP will be used extensively in all future networks and rightfully so. In its current incarnation, however, it lacks basic security controls and methods to properly protect the network itself, not filtering traffic that is supposed to be on the network and not authenticating and authorizing applications, users, and packets to access network resources when they are supposed to. This leads to scenarios in which the “bad guys” can get on components and the “good guys” cannot stop them. Worse, there are situations in which the good guys do not have the basic access or security controls needed to stop the bad guys, and yet they must deal with the aftermath of bad guy access.

TCP/IP is rapidly becoming a security liability. If we are to reverse this ominous trend, protocol and networking experts need to do serious research to formulate all the proper controls, methods, and technologies to ensure that future ubiquity of the TCP/IP protocol provides for reliability, security, and control over traffic. To improve security within the TCP/IP “stack,” vendors of network technologies need to work on the areas outlined below.

Security Programming

Too much critical infrastructure is based upon the TCP/IP protocol in its current state. Emergency reaction networks, critical financial transaction networks, the power grid, process control, water processing, and all manner of critical network infrastructure are using networking as a means to interoperate — without using basic, solid security programming practices and methods. Using an uncontrolled network protocol environment without proper security engineering of applications is a recipe for a security disaster that will affect critical infrastructures throughout the technical universe. Security programming needs apply to the vendor-supplied TCP/IP protocol stacks themselves, base creation protocols (such as ASN.1 and its related compilers), router/switch kernels, secondary supporting protocols (such as ICMP, DNS, DHCP, and others), and all kinds of applications that use the TCP/IP stack to interoperate over a network.

Preconfiguration of Network Applications for Proper Security Operations

A lot of network programs that use the TCP/IP stack for interoperation have some (and in some cases, a lot) of security controls and methods within them. Many times, these controls are intentionally disabled or not engaged, as they require the system integrator or sysadmin to selectively turn on/off the controls as needed. These actions often cause application outages and tech support calls. To reduce vendor costs and headaches, the security controls are disabled to allow easier installation of networked applications, leaving the network door wide open for malfeasance. Vendors of networked applications need to enable security controls out-of-the-box and deal with the support issues that come along with good security practices in order to keep networked applications from becoming network targets at inception of use.

Reengineering of Base Protocols to Address “New” Networked Realities

When TCP/IP was invented in the 1970s, its inventors did not foresee how widely the protocol would come to be used. I know — I have personally spoken to the authors many times over the years about protocol security and related subjects. They have always been quite candid about the lack of security controls in the protocol stack. I am also acutely aware that TCP/IP’s initial mission was not to control power grids, critical financial networks, and the other vital infrastructure (such as 911 networks) that TCP/IP currently provisions. All these crucial uses represent the “new” networked environment, where a weak implementation of security all the way to the base protocol levels results in repetitive and continued attacks on critical infrastructures, which in turn damage components of internetworks.

TCP/IP stacks are now being used in some very critical locations, yet they lack modern protocol controls that would solve a great many security problems. For instance, a cryptographically sound device identification field in the IP protocol header could be used to identify an incoming packet stream back to an exact creation point that could not be spoofed or faked. If a firewall were to have a method by which to authenticate the header to a device authentication database as part of the initial connectivity “handshake,” this would virtually eliminate packet-level DoS and DDdoS attacks — whether the session were encrypted or not. Routers could use such a feature to properly establish route paths and network data flows to deal with quality of service (QoS) and route data management.

Routing update attacks would be nonexistent as well, since routers would know exactly which specific routers are allowed to update route paths and which ones are not. Upgrade of transaction handshakes within a protocol session at random times could ensure that the source of a connection is still the original source and that it has not been hijacked mid-session via some third party. These and many other improvements are needed to create a secure protocol suite that can be used freely in critical infrastructures as part of the new network reality.

Engineering for “What’s Next” in Security Controls

It is not enough to correct a problem simply for the issues that are currently being experienced. Good engineering means looking ahead and dealing with “what’s next” in security controls. A reengineering effort will require a hard look at what types of network challenges and application shifts we will face over the next 10-20 years to ensure that security processes and methods are engineered to handle future network uses. Security controls for bio-implants (e.g., a wireless pacemaker that uses network protocols to adjust settings) are one possible use for future networks. Anything from subcutaneous communications implants to automated transportation systems (e.g., self-driven automobiles) will require a safe and secure networked environment to ensure that they function not only correctly, but securely, to safeguard life.

Securing Wireless Communications

Another major area that will need a lot of work is wireless access. This would include the traditional wireless data networking types (such as wi-fi [802.11] or wi-max [802.16]) but also traditional cellular protocols, which are rapidly being moved into a voice and data mix (CDMA, TDMA, GSM, GPRS, 3G). The big issue here is mostly on the handset side of the equation. Over time, the most popular and ubiquitous access to server technologies will be via wireless handsets, which will be the “super PDAs” of the very near future. Technologies such as VoIP will merge with handset voice methods and will continue to evolve on data access methodologies (as opposed to the current split of data and voice telecom networks).

Children currently in middle school and high school will enter the workplace fully equipped to use handset technologies, having started with text messaging, IM, Internet chat technologies, e-mail, and other applications on wireless handsets provided to them by their parents. They will demand that their wireless handsets provide access to traditional CRM, corporate expense and payroll, e-mail, and other kinds of corporate communications. They will adopt faster data rate technologies, such as 802.16, and will use wireless networking to access home equipment and family communications. They will not want various handsets for corporate voice, personal voice, home voice, and other voice uses. They will use the handsets as a replacement for credit and smart cards, preferring to “beam” credit and debit card information to point-of-sale kiosks and vending machines. They will exchange personal business card and medical information by beaming it to other parties, doctor’s offices, hospital emergency rooms, and police officers (should the occasion arise). Wireless will involve wide area wireless, local wireless, and “piconets” such as Bluetooth, all from the same handset and “talking” to all manner of server applications. The user of the future will be wireless and will require ubiquitous access.

The problems of wireless cyber security start with the handset itself. Most are based on Symbian, Pocket/Mobile Windows, or Palm OS, none of which has reasonable operating system self-protection from infestations such as viruses, worms, Trojan horses, and other attack profiles. Applications written for these systems are usually not secure in form or composition and do not have application security controls that provide for cryptographic privacy measures or protection of personal data (e.g., credit/debit card information) on the handset itself. Handsets typically do not have traditional encrypted VPN services, SSL, or other cryptographic channel connection capabilities. In other words, handsets used in wireless applications are wide open to infiltration, data theft, and DoS attacks.

Wireless transmission is typically in the clear, which makes it easy to grab data via simple tools. Wireless systems have come a long way, especially wi-fi and wi-max, in terms of node authentication (via WPA2). Access methods to the wireless network even exceed traditional wired technologies such as Ethernet/802.3 — provided they are implemented, that is. Unfortunately, users don’t implement most wireless security controls because it is typically nontrivial to turn them on and coordinate all the security methods and management involved.

Standards committees (such as IEEE 802 series) have to do a lot of work to simplify the set-up and management of wireless security before wireless security methods on networks realistically become more secure. This includes automating the set-up of IEEE 802.11x management protocols and security methods, such as the use of WPA2. Key management of encrypted session protocols (such as IPSEC tunnels) also needs to be automated and manual set-up reduced so that these protocols will be widely adopted as the norm instead of being the set-up nightmare they currently are (especially when dissimilar vendor products are used on either end of an IPSEC connection topology). In most situations, especially with wi-fi networks, setting up the wireless component is a simple matter — most vendors have automated the majority of the access point technology set-up. However, the security set-up for the same vendors’ equipment is onerous at best — to the point that most customers don’t even bother to set up security for the wi-fi access points because of the technical effort and time involved.

Achieving Identity Management

Identity management is the third major area in which work needs to be done to solve cyber security issues. Identity can be broken down into devices, programs, and humans. Identity management is the matrix of permissions and access controls that would interact with these three basic IDs to allow/disallow access to a myriad of items that exist on networks and systems. For instance, if a device on a network possessed cryptographically sound credentials, it could use them in an upgraded TCP/IP connection request where a firewall would capture the credentials and use an identity management system to verify whether the device requesting connectivity to a network is allowed to connect. Once verified, the device would be allowed to access the network.  At the very minimum, this type of rudimentary authentication would shut down a wide variety of DoS and DDoS attack types commonly seen on networks today, which also have a debilitating effect on e-commerce.

Identity management is a massive problem. Use of different authentication methods and styles, incompatible software applications, lack of proper use of ID technologies in base connectivity technologies, lack of standards, and a host of other issues make identity management one of the more difficult issues to deal with. But it is also one of the most important issues to deal with, as it is core to many security access methods and controls, both currently in existence or to be created. Identity management is critical to:

• Traceback after attacks

• Proper protection of vast data repositories

• Safeguarding personal information on devices such as wireless handsets

It is a difficult problem that will require a lot of research and a lot of work before a solution set can be created, and this means R&D — a lot of it.

 
For example, one problem that most IT managers will be dealing with very soon is two-factor authentication: the use of two pieces of information to identify an entity, exactly, to another entity. (The two pieces are typically a bit of information about who you are and a bit of information about what you know, presented in a cryptographically sound fashion.) The “who you are” component is rapidly evolving to biometrics or cryptographic identification of one flavor or another. The “what you know” component, traditionally a passphrase of some sort, is evolving to more complex forms of identification, which include soft tokens (cryptographically strong authentication “files” that are pre-placed on a system to identify the system or user), hard tokens (physical devices, which may include biometrics, time-synchronized keys, one-time pads, or other independently generated authentication information), and all manner of exotic identifiers (voice print recognition, facial thermography, etc.). In all situations, users present such identification credentials to the system(s) for access.

This becomes somewhat difficult to manage when various systems use different types of credentials for two-factor authentication. In such cases, the user is forced to physically retain multiple credential provisioning technologies (e.g., multiple biometric devices) to access multiple systems or technical entities — something most users will not tolerate. The system administration of two-factor authentication across multiple entities is a tedious, time-consuming effort even if all the credential types are the same for all systems. When they vary — and they do vary — then the problems creep into the users’ intolerant hands, and they simply do not want multiple credentials for multiple systems.

Enter the concept of federated identity management. This is the idea that a trusted third party becomes the “credential broker” for the dissimilar types of credentials used for two-factor authentication between systems. Getting complex yet? Wait until you include devices that are autonomous and ubiquitous, such as home networking hubs, power meters, and the various kinds of sensor equipment that are becoming automated and online. Current identity management methods are crude and very difficult to manage. Protocols currently in use do not support even these authentication methods, and it will require R&D to properly upgrade the protocols to deal with the new identification realities.

 

LET’S GET THIS PARTY STARTED

As I’ve said, all three of these main issues will require collaborative and extensive R&D to solve. There is no one solution and no one method that will function in all situations. Still, if we do not start the work now, we will not have the technical tools we need to solve basic security issues coming up very quickly in almost every system and networking situation.

Of course, there is always the issue of who should be doing the R&D and who should be paying for it. TCP/IP exists because the US government had a need, funded the research, and created a federal standard for operations of the protocol in its initial uses. Over time, the Internet Engineering Task Force (IETF) has become the “owner” of the protocol suite, but the IETF has become somewhat mired in politics and distracted by numerous other issues that keep it from doing a thorough house-cleaning of the protocol environment in use. Plus, unlike the Advanced Research Projects Agency (now the Defense Advanced Research Projects Agency [DARPA]), which created the initial suite of TCP/IP protocols, the IETF is not funded to do basic, original research.

Most of the technological innovations in internetworking over the last few years have come instead from startups or small communities that had a need and, via the grass roots, created the protocols in wide use today. This method will not work for a massive undertaking of reworking the base protocol of most internetworks. A major effort by a credible and influential organization will be needed to get the R&D accomplished to properly solve TCP/IP protocol suite security issues, especially at the base protocol levels. This may start with original academic research and trials, but to become operational, it will need to involve network carriers and large networking product vendors and suppliers. It’s going to be a group effort unlike anything previously done due to the enormity and complexity of the work needed and the broad effect it will have on the community of network consumers, which continues to grow exponentially.

Other important issues that need to be resolved include such seemingly trivial items as common logging formats for security products. Think it’s not an issue? Name two products from two separate security vendors that have the same event log format. To properly analyze security events, all event traffic from all security sensors and products needs to be consolidated and analyzed by autocorrelation technology to identify issues and problems. Doing this manually is a long and laborious process. It often is not done at all due to the overall difficulty involved.

Good security methodology requires that log files, events, and security information be continually analyzed for anomalous behavior and patterns of poor behavior, and operating patterns of normality must be created against which potential poor operating patterns may be scanned. Scan results can then be used to identity a security situation. R&D needs to happen to properly address the problems of commonality of logging and autocorrelation of events so that meaningful security incidents do not get lost in the infinite mire of logged events.

The point of all of this is that if real security problems are to be addressed, we need to do the technical work. An infinite array of meetings, opinions, and articles will not solve the basics of security, and we will continue to deploy technologies that do not have base security controls implemented within them. In time, as we continue to merge technologies with poor security underpinnings, the problems of security will get worse, and the threats and risks to businesses and individuals will increase.

Bill Hancock is the Executive Vice President and CTO/CSO for Secureinfo Corporation, where he is responsible for global strategy of professional security services, managed security services, and compliance product sets. He is a well-known network and security consultant, designer, and engineer with thousands of network designs and hundreds of hacker/cracker trackdowns to his credit. He is often seen on CNN, ABC, BBC, CBC, NBC, Fox, and other networks as an expert on security, networking, and the Internet. Dr. Hancock has done extensive research on cyber warfare and has consulted and lectured on the subject to industry and governments around the world.