With the world-wide rise of Internet based commerce, we have seen a corresponding rise in cyber crime, not just the capricious "hacking" of teenagers, but more serious organized espionage with the intent of stealing or destroying the intellectual property of high-tech companies. Intellectual property (IP) is the lifeblood of most IC companies, and protection of their IP and their customers' IP is critical to their business.
This article is a primer on digital security, and specifically, how it applies to the protection of an IC company's proprietary information (or Intellectual Property - IP). Our intent is to raise awareness about issues and challenges that need to be considered in securing access to your company's proprietary information and describe some "best practices" that companies implement. This article begins the discussion about the need for security standards and presents a set of common best practices for data access that might ultimately be further developed by the Virtual Socket Interface Alliance (VSIA), and combined with similar existing work covering data storage and transport, into a set of standards for network security.
Attacks, probes, intrusions and other types of exploits are constantly being attempted against corporate web sites and networks. Ask your security department how many times your firewall is probed each month. An associate recently noted that the firewall on his home PC, using a dial-up connection, frequently records 10 or more attempts in an hour. It is important to understand that these probes, threats, and attacks are aimed not just at high-profile, household name companies, but also at smaller, lesser known, and even unknown companies.
Studies conducted by the FBI/CSI, SANS, and CERT, among others, all tend to report a rapid increase in the number of attacks that companies have experienced in the last 5 years. Threats can range from "kids" looking for the challenge and associated bragging rights of breaking in to a site, to more disreputable individuals looking for credit card numbers and other confidential information, to motivated, well-paid professionals who are hired for organized crime and corporate espionage.
At the next level, there are foreign government-sponsored groups strategically looking for weaknesses in the U.S. "critical infrastructure" or information that could be used for competitive advantage. This expands the scope of the problem from the traditional targets of infrastructures supporting financial institutions, utilities, government, and the military to chip manufacturers and the sites of large high technology design or manufacturing companies.
In highly competitive industries and environments, unscrupulous companies may try to obtain information that can help them compete more effectively. They look for data that will give them an edge in the market, including plans, designs, market data, cost/price, specifications, technology partnerships, bid information and any other insight into what their competitors are doing. In short, the information that is useful for building your IP is also useful to them.
Less sophisticated companies may not even know if they have been breached. Possession of security devices and infrastructure is not be enough -- unless you apply and profile the technology correctly, it may not be sufficient to help you when you need it the most. A company needs to have the ability to detect, respond and recreate attacks, and hopefully, identify the attacker.
Finding the right level of security
Given that any security system is a compromise between theoretical perfection and practical reality, this article does not attempt to define a "perfectly secure" system. Instead, a spectrum of recommendations and best practices are defined, with five general levels from which the desired level of security may be compared.
The lowest level defines the minimum level of security that any organization or individual who owns or maintains data processing/storage equipment should implement. The highest level defines the ultimate level of security attainable with state-of-the-art techniques and technologies.
Think of your house and the levels of security you apply to it. At the base level, you put locks on the doors and windows that help keep intruders from simply walking in. However, a minimally skilled person would be able to break the windows. In ascending order of strength, you can add neighborhood watch, gates, moat and alligators or guard towers, and soon, you are reasonably certain that only someone who is motivated and skilled enough for a Hollywood heist film would be able to get into your house.
It should be noted that in determining the "right" level of security for you, there is a return-on-investment (ROI) or break-even point on the costs required to reach the next level. As a general rule, there is an exponential function of the security realized by the increased investment from each level to the next.
A firewall, like locks on doors and windows, protects against someone breaking into your site unnoticed. However, as with the house model, if you require complete information on number of attempts and successful attempts to enter or identification of the intruders, you will need to invest in more elaborate measures, such as card readers or armed security.
The same is true for your IP. In a related observation, Richard Clarke of President Bush's Critical Infrastructure Department has stated, "most Fortune 500 companies spent .0025% of revenue on IT security - less than coffee. [Now], if you spent .0025%, you deserve to be hacked. And by the way, you will be1." This implies that many companies have not been properly concerned about protecting their IP and that there is a lot of room for increasing efforts to protect IP.
In many cases the ROI will not be sufficient to warrant the cost of attaining the highest level of security. It is often the case that the ROI of implementing security improves when security is integrated as early as possible in the architecture or design phase. It is much easier to build security into the architecture than it is to retrofit it. Likewise, the cost of enabling the appropriate level of security for a given situation depends on many factors associated with the size and type of company, type and value of the IP to be protected, and the level of security desired. Individual companies must review their specific ROI versus their needs and exposure.
Establishing a framework
Protecting IP can be a daunting task. The highly sensitive data to be secured may reside on many different systems, be accessible by a wide spectrum of users, be managed by multiple "owners," and will require varying levels of access. In a company with 10,000 employees, securing critical intellectual information is not an easy task, especially with different levels of access for various users.
For example, what is the proper procedure in securing salary information of a large software company? Encryption of the data on the physical disk is a given, but access controls and lockout measures to the files also need to be considered. Securing the underlying operating system, including staying patched and installing updates, is critical. The network also needs to be considered, including firewall or router Access Control Lists (ACLs), access to different subnets, or management networks. Additionally, business needs and functional requirements need to be supported, such as the need for 75 percent of the company to access critical information on a daily basis, both from work and at home, combined with the fact that out of the 75 percent that need access, only 74 percent are care about security.
Protecting data, whether it is salary information or IP, can be difficult. Unlike salary information, IP needs to be accessed by employees on a daily basis from everywhere the company does business. This has come to include remote offices, hotels rooms, external business partners and employee's homes. When properly implemented, security measures and procedures can help an organization's security needs and add a level of functionality for many users.
This article organizes IP security into three general areas:
- Access (internal and external), including authorization and authentication of users
- Storage (physical storage), including host systems
- Transport (network facilities), including Local Area Networks, Wide Area Networks and Virtual Private Network technologies.
The delineation between these components is often difficult to define due to the way IP is distributed throughout a company's infrastructure (networks and host systems), the wide range of applications that use IP and the new remote networking methodologies such as VPN and tunneling. This article will discuss only the first of these components in detail, namely access.
Access to data that supports business and technical development needs to foster openness. Information flowing easily from a data center to an authorized user does not have to mean that no security was involved. The process of securing the data must be efficient in order to be practiced.
Internal authorization and authentication
Each department should establish data ownership. Additionally, different levels of authorization should be established to determine the type of access to information a database engineer would have (level 4) versus a sales engineer (level 1). After data ownership is established between departments, the right to grant or deny individuals and/or departments needs to be determined. The determining factor of classes should be based on job requirement, job responsibility and functional duties.
Each department should have a qualified class level. Depending on the different levels of data classification and ownership, different levels of authentication would be required. The following is an example of possible classification types and authorization requirements for a chip manufacturer:
Figure 1 - Levels of security authentication
Internal authentication types
There are several authentication mechanisms that can be used individually or in combination. Username and passwords are the first level. However, any username and password used for authentication should always use secure encrypted protocols such as Kerberos, SSH, IPSEC, or NTLMv2. Protocols used for authentication that have known security problems should be restricted, such as NTLM, Telnet, FTP, Citrix, or PPTP. The insecure protocols add weaknesses to the overall authentication system, and therefore, should not be used.
A second level of authentication can be added through operating system ACLs. Specific permissions and/or restrictions should be placed on both the file and network level. Restrictions to individual files and folders should be implemented in addition to the ability to have access (authentication rights) to logon to the machine. Below is a screen shot of IP Filters in Windows 2000.
Figure 2 - IP filter list in Windows
The third level of authentication is a public and private key combination. There are several ways to use a public/private key system, including SSH (Secure Shell). Using SSH, the user would be required to hold a public key and private key to authenticate to a particular server. Both the server and client would be required to hold the user's public key. The client needs both a private key and a correct password to authenticate to the public key.
After authentication to the public key, the public key would be used to authenticate to the server, which also has a copy of the users public key to match credentials. Using this scenario, a lost username and password does not grant any access unless the unauthorized user has managed to capture the public and private key of the authorized user, which should be stored in two separate and secure places on the operating system. The following is a graphical representation of SSH.
Figure 3 - Secure Shell (SHH)
The fourth level of authentication could be a hardware token, such as SecureID from RSA. SecureID requires a user to physically posses a hardware token, the SecureID object, to be used for authentication. Without going into detail about SecureID, the token displays a changing password authentication scheme where the user would need to authenticate to the appropriate server. Therefore, an attacker who successfully steals a username, password and both SSH public and private keys will be blocked if they do not physically possess the appropriate SecureID token.
Internal authentication tracking
After authentication has been completed, the use of privileged user or department credentials should be tracked. It is difficult to impossible to verify if any unauthorized use is occurring without the proper audit trails and timestamps. In additional to providing evidence on when the data was accessed and by whom, log files provide a method of tracking who is viewing what, and thus, if and when someone has copied sensitive information. As a policy, users should be required to work on appropriate and secured servers. When dealing with IP appropriate logging measures provide an organization with the necessary information and controls to improve the protection of their data.
Internal console privacy
Console privacy can be as simple as it sounds -- simply controlling physical access to one's machine. Protecting intellectual property requires steps beyond screensaver passwords, such as using disk encryption software to control access to sensitive information on the local drive. Additionally, BIOS passwords should be implemented to prevent the ability to boot off of other media, such as a CD-ROM or floppy disk, and thus gain access to an operating system's folders and password files. Below is a chart describing recommended levels of console security methods.
Figure 4 - Levels of console security
The IT security policy needs to clearly define the corporate policy for offsite remote access. External users should be categorized into security profiles, based on desired type of remote access, to ensure that critical information is not going offsite to unauthorized users. The user categorization will allow employers to clearly define what type of access rights require a given type of security precaution (such as username and password) versus multiple levels of security. The following chart shows an example of 5 different levels of access for remote users.
Figure 5 - Remote user classification
External authentication needs to be multi-factored and controlled, with proper auditing in place. Different levels of external authorization should be established and correlated to the classification of the user. For example, a network administrator would have (level 4) and a project manager might only need (level 2). After user classification is established, the ability to grant or deny individuals and/or departments can be determined. The classification factor of classes should be based on desired access, job responsibility and functional duties. Depending on the different levels of user classification, different levels of authentication would be required. The following is an example of possible classification types and authorization requirements:
Figure 6 - Levels of security authentication
External remote access
Remote access for external untrusted sites, such as the Internet and business partner locations, needs to be easy and streamlined, without adding complex levels of security. Level 1 (for email users) and level 2 (for email and access administrative applications such as calendars) can simply dial into networked devices that accept incoming connections on a regular phone line or Ethernet connection. This process can be accomplished with a variety of devices, such as Cisco's RADIUS server, Microsoft's VPN (PPTP) server, and Sun Microsystems' Sunscreen server. The user is required to enter in a username and password and then access email.
Levels 3 to 5 (which require access from regular file servers to sensitive data stores) should have a multi-factor authentication. The external user is required to have a regular username/password to access email and calendar applications, along with additional passwords, authentication keys, or SecureID/one-time passwords to access other devices in different parts of the internal network. Devices that are involved in these levels are SSH servers, VPN servers, RSA servers, and so forth. These devices support all types of platforms (Microsoft Windows, Sun Solaris, and all types of Linux operating systems) that the end user may be using. Additionally, all three of these further layers of authentication can be virtually invisible or highly streamlined to the end user, thus hiding any complexity.
In additional to SSH, VPN, and Secure IDs remote access methods, all level 3 to 5 users should have a secured operating system from where the remote user can access the company's critical resources. An insecure workstation combined with a very secure remote access solution equates to a weak link in the network. An attacker could compromise a user's workstation and use the existing VPN or SSH connections to the corporate network to access information and steal/modify data. Since remote access methods usually subvert most firewalls, attackers would target these attack methods.
In most networks, information is passed from a variety of locations and in a variety of ways, both in the internal network and external network. With the increase of business partner networks and extranets, it is important to understand what is happening on a company's network, especially in areas where external users may be allowed access. Monitoring, whether it be Intrusion Detection Systems (IDS), operating systems logs or firewall logs, needs to be in place and at appropriate levels.
Appropriate logging and IDS devices may allow an administrator to see that a certain network is being attacked or that an external user just logged into the source code database. Not only would this information provide real-time alerts to appropriate administrators, but also provide post-mortem understanding of a possible security event or situation. The lack of IDS monitor or log collection may allow attackers to virtually go unnoticed for several weeks, or even months, if there is nothing there to trace unauthorized access or even suspicious use.
A best practice for monitoring is to deploy a central log server in a given network, such as a Syslog server. A central log server can hold critical information from all types of devices in the network, including firewalls, routers, Solaris systems, and Microsoft systems, allowing an administrator to view and analyze log data from a central and convenient location.
In addition to providing a central repository for analysis, a central log server also increases security by moving critical log information off of regular systems and into a secured log server. If an attacker were to compromise a machine, he/she would probably delete all log information immediately, thereby removing any trace of his/her activities. However, if all logs are exported to a secured central log server, the attacker would not be able to remove any traces.
Thus far we have discussed data as it is transferred through internal and external networks and how to protect it over the wire. However, after the data reaches the disk, how secure is it? Let's say that all the protocols are secure, from SSH and SSL to IPSec, and now the data is sitting on a physical disk drive; is it still susceptible to attacks? Data in storage is one of the most common perceptions of trust, meaning that security usually focuses on protocols and architecture, not the actual data on the disk.
The data on the disk is often considered to be safe, since multiple firewalls and encryption is used on the network, therefore, the data doesn't need to be protected on the physical disk, right? Not necessarily! The truth is that data in storage would be exposed if an unauthorized person were able to worm their way onto the drive.
The obvious solution is encryption of the data on the disk, but how does that affect the functionality of the network and the ability of employees to do their job without overbearing security controls? The answer to that question is never easy, in fact, it usually is never asked, because there is not a good solution that addresses all vulnerabilities. However, the solution does not have to encompass everything, just as long there is a solution that protects the data in storage more than in the file system permissions. Furthermore, the solution does not have to be overly complicated, and products such as PGP, E4M, and Protegrity can help address many of these issues.
The first step is similar to the approach in previous discussion. However, instead of simply considering the ownership of the data, we need to consider the sensitivity of the data. To begin, each organization needs to establish data sensitivity categories. Different levels of sensitivity will determine the type of encryption to use or not to use on the disk and depending on the different levels of data sensitivity, different levels and types of encryption would be required. By this means, as with data access, we can similarly define levels of security and best practices for data storage.
Once authenticated clients are making connections to hardened servers, there are still two areas of concern. Is the transport link secure, and is the client appropriately protected? These issues are generally not a problem inside a corporate network where firewalls and switched networks are common. However, more and more work is being done off site, whether in a home network, hotel room or even on-site inside another company. The subject of transport (like access and storage) is also readily amenable to definitions of security levels and best practices.
Protecting IP is a step-by-step procedure, where the steps range from classifying data in a given network to installing a host-based firewall on a remote laptop. Keep in mind that all steps gradually increase the security posture of an organization and make an environment more secure, and most importantly, more functional. Securing IP is not about locking users out or applying rigorous security controls, but rather understanding the business requirements of an organization and intersecting it with security best practices.
1 Richard A. Clarke, Special Advisor to the President for Cyber Security. February 14, 2002. Also, Wired Digital, Inc. Wired Magazine. "The Sentinel" by Declan McCullagh, Washington Bureau Chief for Wired News, October 2000.
VSIA White Paper: Technical Measures and Best Practices for Securing Proprietary Information
C/Net News.com, C/net Networks, Inc.
Computer Security Institute (CSI)
Computer Security Institute/FBI Survey
Secure Business Quarterly
System Administration, Networking and Security (SANS) Institute
Wired News, Wired Digital, Inc.
Ian R. Mackintosh (email@example.com) is president of OCP-IP and vice president of Sonics, Inc.. He is a board member of VSIA and chair of VSIA's Intellectual Property Protection Development Working Group (IPP DWG). Mr. Mackintosh is well known in the EDA and semiconductor industries and served formerly as a Steering Committee Member for the Virtual Component Exchange (VCX).
Himanshu Dwivedi (firstname.lastname@example.org) is a managing security architect at @stake and a member of VSIA's IPP DWG. His professional experience includes application programming and security consulting, with an emphasis on secure network architecture and server risk assessment of Windows and UNIX. At @stake, he forms part of the San Francisco-based Professional Services Organization (PSO), providing clients with attack and penetration services, secure network design, and secure server analysis.