Vsia Ip Protection Measurements

VSI AllianceTM White Paper Technical Measures and Best Practices for Securing Proprietary Information Version 1.
0
(IPPWP3 1.0)
Issued by the Intellectual Property Protection Development Working Group

November 2002
VSI Alliance (IPPWP3 1.0)
NOT LEGAL ADVICE The discussions of the law in this document are not intended to be legal advice. This document is not to be used as a legal reference. Readers should refer to their own legal counsel for answers to questions concerning the law.
Copyright 2002 by VSI Alliance, Inc. 15495 Los Gatos Boulevard, Suite #3 Los Gatos, California 95032, USA Phone: (408) 356-8800, Fax: 408-356-9018 http://www.vsi.org, info@vsi.org
VSI Alliance is a trademark of the VSI Alliance, Inc. All other trademarks are the property of their respective owners.
Please send comments and questions to: IP Protection Development Working Group (DWG), VSIA
Ian R. Mackintosh Chair 3054 Three Springs Road, San Jose, CA 95140 408-406-3152, ian@sonicsinc.com Raymond Burkley Vice-Chair Burkley Associates, P. O. Box 496, Cupertino, CA 95015 408-735-1540, rburkley@netgate.net VSI Alliance 115495 Los Gatos Blvd, Suite 3, Los Gatos, CA 95032 408-356-8800, info
Copyright 2002 by the VSI Alliance, Inc. All Rights Reserved. VSIA CONFIDENTIAL DOCUMENT
ii
Notice
The document is provided by VSIA subject to a license agreement, which restricts how this document may be used.
THIS DOCUMENT MAY NOT BE COPIED, DUPLICATED, OR OTHERWISE REPRODUCED. THE DOCUMENT IS PROVIDED BY VSIA ON AN "AS-IS" BASIS, AND VSIA HAS NO OBLIGATION TO PROVIDE ANY LEGAL OR TECHNICAL ASSISTANCE IN RESPECT THERETO, TO IMPROVE, ENHANCE, MAINTAIN OR MODIFY THE DOCUMENT, OR TO CORRECT ANY ERRORS THEREIN. VSIA SHALL HAVE NO OBLIGATION FOR LOSS OF DATA OR FOR ANY OTHER DAMAGES, INCLUDING SPECIAL OR CONSEQUENTIAL DAMAGES, IN CONNECTION WITH THE USE OF THE DOCUMENT. VSIA MAKES NO REPRESENTATIONS OR WARRANTIES, EXPRESS OR IMPLIED, INCLUDING WITHOUT LIMITATION, ANY WARRANTY AS TO INFRINGEMENT, OR THE IMPLIED PURPOSE. THE READER SHOULD BE AWARE THAT IMPLEMENTATION OF THE DOCUMENT MAY REQUIRE USE OF SUBJECT MATTER COVERED BY PATENT OR OTHER INTELLECTUAL PROPERTY RIGHTS OF THIRD PARTIES. NO LICENSE, IMMUNITY, OR OTHER RIGHT IS GRANTED BY USE OF THIS DOCUMENT IN ANY SUCH THIRD-PARTY RIGHTS. NEITHER VSIA NOR ITS MEMBERS TAKE ANY POSITION WITH RESPECT TO THE EXISTENCE OR VALIDITY OF ANY SUCH RIGHTS.
iii
iv
Intellectual Property Protection Development Working Group

Company Members
ARM ECSI Fujitsu Mentor Graphics Philips Semiconductor Cadence Design Systems Ellipsis Digital Systems IBM Oki Telecom VCX
Individual Members
Raymond Burkley (Vice-Chairman) Suzanne P. Harrison Ken Hodor Ian R. Mackintosh (Chairman) Brahmajai Potu Patrick H. Sullivan Eduardo Charbon Robert Helt Gerald N. Keeler Miodrag Potkonjak Gang Qu Joseph F. Villella, Jr.
Current DWG Member Representatives

Simon Watt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ARM Richard Terrill . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Cadence Design Systems Mark Bales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Cadence Design Systems Adam Morawiec . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ECSI Minesh Shah . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Fujitsu Ltd. Takeshi Fuse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Fujitsu Ltd. Ken Goodnow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .IBM Ken Hodor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Individual Member Ian R. Mackintosh (Chair) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Sonics Al Kwok . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . NetLogic Microsystems Tadashi Hiruta. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Oki Electric Industry Miodrag Potkonjak . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Individual Member Patrick Beauvillard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Individual Member Raymond Burkley (Vice-Chair) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Individual Member Larry Rosenberg . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . VSIA-TC Chair
Authors
Himanshu Dwivedi Robert Helt Myles Conley
vi
Revision History
Version 1.0 Version 1.0 Version 1.0 Version 1.0 Jun02 Oct02 Oct02 Nov02 Draft edited and formatted for member review Copy edited for IPP DWG review Copy edited and formatted for Board review Formatted for final release
vii
viii
Table of Contents
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 Finding the Right Level of Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
Establishing a Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5
Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 Storage. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 Transport . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .23 A. About the Authors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25 B. Bibliography . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 C. Glossary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .29 List of Tables
Table 1: Authorization and Authentication. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 Table 2: Levels of Console Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 Table 3: Remote Users Classification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 Table 4: Levels of Security Authentication. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 Table 5: Levels of Security Encryption. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 Table 6: Layers of Transport Security. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
List of Figures
Figure 1: IP Filters in Windows 2000 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 Figure 2: Graphical Representation of SSH (Secure Shell) . . . . . . . . . . . . . . . . . . . . . 8 Figure 3: EM4 File System Encryption - Example 1 . . . . . . . . . . . . . . . . . . . . . . . . . 15 Figure 4: EM4 File System Encryption - Example 2 . . . . . . . . . . . . . . . . . . . . . . . . . 15 Figure 5: EM4 File System Encryption - Example 3 . . . . . . . . . . . . . . . . . . . . . . . . . 16 Figure 6: PGP Encryption - Example 1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 Figure 7: PGP Encryption - Example 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 Figure 8: PGP Encryption - Example 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 Figure 9: PGP Encryption - Example 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 Figure 10: Example of Best Practices for Protecting IP . . . . . . . . . . . . . . . . . . . . . . . 24
ix
Introduction
Preface
This white paper is a primer on digital security, and specifically, how it applies to the protection of a companys proprietary information (or Intellectual PropertyIP). A survey of VSIA members in early 2001 showed us that many of you are directly involved in the everyday development, management, or use of proprietary information for your companies. This same survey told us that protecting this information from theft, misappropriation, compromise, and unauthorized access through your companys networks and systems is of tremendous current interest. Our intent is to raise awareness about issues and challenges that need to be considered in securing Access, Storage, and Transmission of your companys proprietary information and describe some best practices that companies implement. We assume only that you, or someone you work with, ultimately owns your organizations IP and that while you personally may not have direct responsibility for deciding specific security technologies and options that your company deploys, you will want to or need to discuss this security with IT professionals. This paper begins the discussion about the need for security standards, and presents a set of common best practices that might ultimately be extended in recommendation form for VSIA member companies.
Scope
The purpose of this document is to begin to define standards and best practices for securing intellectual property (IP) from external (outside the corporate perimeter) attacks and internal (inside the corporate perimeter) compromise. It covers protection for IP that is stored and for IP that is transported over data networks. This paper is for anyone in the SoC design community who is involved in the development and management of designs, documents, specifications, and other information that is considered the lifeblood or IP of the business. At one level, securing critical information from unauthorized access is the responsibility of all employees. However, since IP is one of the pillars the company is built upon, it is particularly necessary that everyone who develops, manages, or uses the companys IP must ensure that it is handled, distributed and stored with all due care.
Background
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 IP Protection (IPP) Development Working Group (DWG) member 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 five 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.
Copyright 2002 by the VSI Alliance, Inc. All Rights Reserved. VSIA CONFIDENTIAL DOCUMENT 1
VSI Alliance (IPPWP3 1.0) At the next level, there are foreign government-sponsored groups strategically looking for weaknesses in the US 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 manufacturing and commerce 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. Take the case of Microsoft. In October, 2000, according to BBC News1 published reports, Microsoft discovered that someone had gained unauthorized access to its internal systems and may have viewed some of the source code of key programs under development. While it was reported that no source code had been taken or compromised, Microsoft spokesman Rick Miller characterized the break-in as a deplorable act of industrial espionage. Microsoft called in the FBI to assist in the subsequent investigation. What is compelling about this story is that it happened to Microsoft, which knows that it is a target for a wide range of attackers. Microsoft has taken the necessary precautions to protect itself with firewalls, intrusion detection devices, and other sophisticated technology, and has a world-class security management team that knows how to plan for and respond to attacks. According to the BBC News report, even with its technology and expertise, Microsoft was not immediately sure how long the attacker had been able to access its network. The original statements indicated up to five weeks, but were later proven to be twelve days. Other, less sophisticated companies may not even know if they have been breeched. Possession of security devices and infrastructure cannot 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 to, and re-create 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 specification 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 and storage equipment should implement. The highest level defines the ultimate level of security attainable with state-of-the-art techniques and technologies.
1.
BBC News, October 30, 2000: http://news.bbc.co.uk/hi/english/business/newsid_998000/998449.stm 2
VSI Alliance (IPPWP3 1.0) 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. It would take someone with more proficiency and motivation to pick your locks, and while this raises the skill level needed to break in, the end result is that someone is still able to breech your security. You can add an alarm system and motion detectors to alert you and the local police department that someone has entered the perimeter and tripped the alarm. The intruder, while under a definite time constraint, still has some time to get something of value and run. You can add a dog, which will give you additional advanced notice, but might be circumvented with a bone. 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-oninvestment (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. This is because there is a diminishing return from implementing a new security technology and the vulnerabilities it can address relative to your total security exposure. 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 order to elevate the bar for the skill required to breech your current level of security, an investment must be made that must be valued against the information you are protecting. In a related observation, Richard Clarke of President Bushs Critical Infrastructure Department 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 be.2 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 level of security desired; the size and type of company; the type and value of the IP to be protected; and so on. The cost and ROI need to be analyzed on an individual company basis to meet the needs and financial capabilities of the company.
Speech by 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. http://www.wired.com/wired/archive/10.03/clarke_pr.html Copyright 2002 by the VSI Alliance, Inc. All Rights Reserved. VSIA CONFIDENTIAL DOCUMENT 3
2.
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 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 for securing salary information for 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 patches and 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. This is combined with the fact that out of the 75 percent that need access, only 74 percent 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 employees homes. When properly implemented, security measures and procedures can help an organizations security needs and add a level of functionality for many users. This document 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 companys infrastructure (networks and host systems), the wide range of applications that use IP, and remote networking methodologies such as VPN and tunneling.
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 is involved. Most importantly, the process of securing the data must be efficient in order to be practiced.
VSI Alliance (IPPWP3 1.0) 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 needs (level 4) versus the access that a sales engineer needs (level 1). After data ownership is established between departments, the right to grant or deny individuals 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. For example, if you are in department X with the Y job functions and Z responsibilities, you might be granted an authorization rating of 4. The level will not only determine what portions of the IP you may access, but also determine what type of authentication is required to access that information. 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:
Table 1: Authorization and Authentication
Levels of Security Authentication
LEVEL 1 DESCRIPTION Contractors, guests, and other temporary positions Sales, HR, finance AUTHORIZATION TYPES Username and password ADDITIONAL ACCESS CONTROLS Operating system security
Username and password, public/private key authentication Username and password, public/private key authentication
Operating system security
IT department, management network, sensitive subnets IP departments, engineers and departments that support the chip design IP departments/ engineers working on chip design
Operating system security, firewall rulesets and router ACLs
Username and password, public/private key authentication, hardware tokens
Operating system security, firewall rulesets and router ACLs, operating system ACLs
Username and password, public/private key authentication, hardware tokens, One time password usage system
Operating system security, firewall rulesets and router ACLs, operating system ACLs
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, NTLMv2, and so on. Protocols used for authentication that have known security problems should be restricted, such as NTLM, Telnet, FTP, Citrix, PPTP, and so on. The insecure protocols add weaknesses to the overall authentication system, and therefore, should not be used.
VSI Alliance (IPPWP3 1.0) A second level of authentication can be added through operating system ACLs. Specific permissions 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 log on to the machine. For example, a user in department Z, security level 4, should be given specific rights to access appropriate folders and denied for the rest. On UNIX systems, the TCP wrapper program should be implemented to grant access only to appropriate users from specific IP addresses or subnets. The Windows 2000 IP Filters offer similar functionality. Therefore, even if an unauthorized user possesses a valid username and password for the user in department Z, authentication does not succeed unless the user connects from the appropriate subnet. The following figure shows a screen shot of IP Filters in Windows 2000.
Figure 1: IP Filters in Windows 2000
VSI Alliance (IPPWP3 1.0) The third level of authentication is a public and private key combination. There are several ways to use a public and private key system, including SSH (Secure Shell). Using SSH, the user is required to hold a public key and private key to authenticate to a particular server. Both the server and client are required to hold the users 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 is 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 figure shows a graphical representation of SSH.
2. SSH public key sent
3. SSH public successfully matched
1. SSH password matched against private key 4. SSH session begins NOC Workstation Secured Server
Holds SSH Public and Private keys
Holds SSH Public keys
Figure 2: Graphical Representation of SSH (Secure Shell)
The fourth level of authentication could be a hardware token, such as SecureID from RSA (please refer to www.rsa.com for more information). SecureID requires a user to physically possess 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 which the user needs to authenticate to the appropriate server. Therefore, attackers who successfully steal a username, password, and both SSH public and private keys are blocked if they do not physically possess the appropriate SecureID token.

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 information, if or what something has been copied, and if someone has copied sensitive information. As a policy, users should be required to work on appropriate and secured servers. For example, if any authorized user copies IP to inappropriate servers, unauthorized access should be suspected even though the user is granted the highest security clearance. Copying any IP information off of authorized servers should be strictly prohibited. Furthermore, if any removal of the information occurs, even by an authorized user, the event needs to be recorded. For example, authorized users may copy a piece of data to their local machine. However, in most environments, the users local machine may be insecure or shared between various users who do not possess the same level of clearance. This situation is a direct violation of security because the data is now in greater jeopardy. When dealing with IP, appropriate logging measures provide an organization with the necessary information and controls to improve the protection of their data.
Console Privacy
Console privacy can be as simple as it sounds: simply controlling physical access to ones machine. However, a screensaver on a Windows 9x machine should not be the only measure. There are many ways to get the password from a Window 9x screensaver, which, if the unauthorized user is lucky, will be the same password that the user uses on the network. 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 systems folders and password files. The following table describes recommended levels of console security methods.
Table 2: Levels of Console Security
Levels of Console Security
LEVEL 1 DESCRIPTION Contractors, guests, and other temporary positions Sales, HR, Finance CONSOLE SECURITY METHODS Screen saver passwords
Screen saver passwords, Encrypted PGPdisk/E4M disk, BIOS passwords Screen saver passwords, encrypted PGPdisk/E4M disk, BIOS passwords Screen saver passwords, encrypted PGPdisk/E4M disk, BIOS passwords Screen saver passwords, encrypted PGPdisk/E4M disk, BIOS passwords
IT department, management network, sensitive subnets IP departments/engineers and departments support the chip design IP departments/engineers working on chip design
VSI Alliance (IPPWP3 1.0) External

Authorization
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. For example, users who simply need to use email from remote sites will probably pose a smaller risk than users doing remote development work on source code or databases. The user categorization allows employers to clearly define what type of access rights require a basic level of security precaution (for example, username and password) as opposed to multiple levels of security. The following table gives an example of five different levels of access for remote user.
Table 3: Remote Users Classification
Remote Users Classification
LEVEL 1 TYPE OF ACCESS Email access DESCRIPTION A level 1 type of user will only require access to email from off-site locations. A level 2 type of user will require access to email and other administrative applications; however, none of this information is sensitive or critical to the employers core business.
Email access On-line administrative applications (calendaring, timesheet apps, and so on.) Email access On-line administrative applications (calendaring, timesheet apps, and so on.) File server access Email access On-line administrative applications (calendaring, timesheet apps, and so on.) File server access Sensitive file servers Email access On-line administrative applications (calendaring, timesheet apps, and so on.) File server access Sensitive file servers Critical data stores
A level 3 type of user will require both level 1 and 2 types of information and will require access to actual files and file servers in the internal network. However, the files and/or servers are not considered to hold IP.
A level 4 type of user will require all of the above and access to information and/or servers that are sensitive and critical to the employers core business practices and strategies. A level 4 type of user will have access to the companys business goals and financial statement.
A level 5 type of user will require all of the above and access to information and/or servers that hold sensitive data stores that are critical to the employers core product or service line. A level 5 type of user will have access to source code files and other types of IP.
10

Authentication
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 might need level 4, and a project manager might only need level 2. After user classification is established, the ability to grant or deny individuals or departments can be determined. The classification factor of classes should be based on desired access, job responsibility, and functional duties. For example, if a user needs to access source code information for a business partner network, the user will be classified as level 4 and required to use the appropriate types of authentication. Depending on the different levels of user classification, different levels of authentication would be required. The following table gives an example of possible classification types and authorization requirements.
Table 4: Levels of Security Authentication
Levels of Security Authentication
LEVEL 1 Email access TYPE OF ACCESS AUTHORIZATION TYPES Username and password TYPES OF TYPICAL USERS Contractors, guests, and other temporary positions Sales, HR, finance
Email access On-line administrative applications (calendaring, timesheet apps, and so on.) Email access On-line administrative applications (calendaring, timesheet apps, and so on.) File server access Email access On-line administrative applications (calendaring, timesheet apps, and so on.) File server access Sensitive file servers Email access On-line administrative applications (calendaring, timesheet apps, and so on.) File server access Sensitive file servers Critical data stores
Username and password
Username and password, public/private key authentication, VPN (IPSEC) tunnels Username and password, public/private key authentication, VPN (IPSEC) tunnels, Secure ID token
IT department, management network, sensitive subnets
Executive positions and financial departments
Username and password, public/private key authentication, VPN (IPSEC) tunnels, Secure ID token, one-time password usage system
IP departments/engineers working on chip design
11

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 users (for email) and level 2 users (for email and access to administrative applications such as calendaring) can 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 the Cisco RADIUS server, Microsoft VPN (PPTP) server, and Sun Microsystems Sunscreen server. The user is required to enter a username and password in order to 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 and password to access email and calendaring applications, along with additional passwords, authentication keys, or SecureID or 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 on. 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 SecureID remote access methods, all level 3 to level 5 users should have a secured operating system from which the remote user can access the companys critical resources. An insecure workstation combined with a very secure remote access solution creates a weak link in the network. An attacker could compromise a users workstation and use the existing VPN or SSH connections to the corporate network to access information and steal or modify data. Since remote access methods usually subvert most firewalls, attackers target these attack methods. (More information on DSL and Cable home users is provided in the Transfer section.)
Monitoring
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 companys network, especially in areas where external users may be allowed access. Monitoring, whether by Intrusion Detection Systems (IDS), operating systems logs, or firewall logs, needs to be in place and at appropriate levels. Appropriate logging and IDS devices 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 does this information provide real-time alerts to appropriate administrators, but it also provides 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 nothing traces unauthorized access or 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.
12
VSI Alliance (IPPWP3 1.0) 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 attackers compromises a machine, they will probably delete all log information immediately, in order to remove all traces of their activities. However, if all logs are exported to a secured central log server, the attacker would not be able to remove any traces, thus increasing the likelihood of catching the incident and recovering a possible loss.
Storage
Thus far, we have discussed data as it is transferred through internal and external networks and how to protect data over the wire. However, after the data reaches the disk, how secure is it? Lets 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 are used on the network. However, the truth is that data in storage is exposed if an unauthorized person is 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, this issue is not usually addressed because there is not a good solution that addresses all vulnerabilities. However, the solution does not have to encompass everything, 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 (www.pgp.com), E4M (www.e4m.net), and Protegrity (www.protegrity.com), can help address many of these issues. The first step is similar to those discussed in prior sections. However, instead of simply considering the ownership of the data, we need to consider the sensitivity of the data. For example, the core source code for Windows 2000 is important to protect; however, freely available libraries and data files that the source code includes are not necessary to protect. It is very important to classify the proprietary data on the disk into categories that are appropriate for the environment, and classification can be as simple as not sensitive, sensitive, and highly sensitive. The first step is for each organization to establish categories for data sensitivity. Different levels of sensitivity will determine the type of encryption to use or not to use on the disk. Core (kernel) source code data needs a higher level (level 1) than data for shared libraries (level 4). Furthermore, core source code data requires a high level of encryption on the disk, and should only be accessible to core individuals that have a business requirement to access the information. Using the above scenario, data that is involved in the final design was actually taken from industry standards, so it requires low to no levels of encryption, and therefore, the data can sit in the clear.
13
VSI Alliance (IPPWP3 1.0) Depending on the different levels of data sensitivity, different levels and types of encryption are required. The following table gives an example of possible classification types and encryption requirements for a chip manufacturer.
Table 5: Levels of Security Encryption
Levels of Security Encryption
LEVEL 1 DESCRIPTION Free available data sets None ENCRYPTION TYPES N/A EXAMPLE TOOLS
Propriety code for products that do not highly influence the financial statements of the company Propriety code for products with highly bloodthirsty competitors
Encryption of data in shared file systems Encrypted databases
PGP, E4M Protegrity, Oracle 9i
Encryption of data in shared file systems Encryption of individual data sets Encrypted databases Encrypted email
PGP, E4M PGP Protegrity, Oracle 9i PGP PGP, E4M PGP, E4M PGP Protegrity, Oracle 9i PGP
Core source code for all products
Encrypted file system on all workstations Encryption of data in shared file systems Encryption of individual data sets Encrypted databases Encrypted email
14
VSI Alliance (IPPWP3 1.0) File System Encryption File system encryption means having a data drive encrypted. This drive can hold multiple data sets, files, folders, binaries, C and C++ files, and so on. Whether this encrypted file system is on a local workstation or on shared resources, a proper username and password and/or a private key would be required to decrypt the drive to access the data. The following two examples show a publicly available tool for file system encryption and the Windows 2000 method of file level encryption (Encrypted File System [EFS]).
Figure 3: EM4 File System Encryption - Example 1
E4M mounts an entire encrypted file system with a valid password that cannot be viewed to unauthorized users.
15
VSI Alliance (IPPWP3 1.0) The encrypted file system appears after successful authentication.
File or folder encryption can be used on Windows 2000 for both local and remote resources. Data Set Encryption Data set encryption involves encrypting individual files or datasets themselves. These files can range from a C++ file to a JAVA library file that is propriety to the organization. Data set encryption is encrypted on an individual level, with each file requiring a username and passwords for valid authentication. Below is PGP encryption for an individual file.
Figure 6: PGP Encryption - Example 1
The user selects which individuals are authorized to view the file.
16
PGP encrypts the individual file.
The encrypted file is created.
17
A valid passphrase is required to decrypt the file for usage. Notice that only the authorized user who was initially selected is able to attempt to decrypt and view the file. Database Encryption There is a lot of concern about the amount of encryption used in databases. Since most core data to products and designs are in databases, such as Oracle, MS-SQL, or mySQL, database encryption is of primary concern. Database encryption provides a method for valid users to view only the materials they need to perform their business functions. With database encryption, if an unauthorized user is able to subvert the file system permission, a valid passphrase or private key is needed to view the data, or else the unauthorized user would just view encrypted garbage. This method protects against weak or non-exiting file permissions and allows all database information to be sitting on the disk in an encrypted format. Protegrity is one example of software that can be used for encryption on databases. Additionally, Oracle 9i (www.oracle.com) inherently provides database encryption with its software package. Email Encryption An email containing any amount of IP must be appropriately secured. Email protocols are in clear-text, and email systems are often popular targets. With todays ever-growing electronic commerce, email is the prime source for communication. However, email has also become the prime source for the exchange of files, datasets, and code between co-workers or office locations. With this trend, propriety information is being sent out of the company into remote mailboxes and remote email systems that anyone can access, including Hotmail and Yahoo. Policies need to support the use of secure email protocols and attachments. This may be as severe as outbound email servers stripping out all attachments with any non-encrypted attachments. PGP and other commercial tools can be used to encrypt email attachments, as well as to encrypt the actual text of the email itself. Additionally, secure protocols such as IMAP over SSL (SIMAP) can be used to prevent unauthorized users from monitoring messages over the wire (as described earlier in this document). Encryption of email servers adds significantly to the overall protection of a targeted resource that usually contains proprietary information.
18
Transport
Once authenticated clients are making connections to secure servers, there are still two areas of concern: the transport link must be secure, and the client must be 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 on-site inside another company. This section describes methods for ensuring that data transported over public networks is appropriately protected. Link Level Security Many of the methods used for non-corporate networks involve media shared among many users. While wireless networks are an extreme example, many cable modems and DSL networks also allow anyone in the neighborhood to monitor traffic or scan local hosts. Hosts that initiate VPN connections to major corporations also announce themselves as interesting targets. Even a single exchange of data over the Internet using PPTP can be enough information for a sniffer or decryption software to access critical data. As mentioned above, clients allowed to make VPN connections to the corporate network must be secured in a manner commensurate with the corporate firewalls. This includes all of the requirements for firewalled protocols, network interconnection, virus checking, and strong authentication of inbound traffic. Newer operating systems now include some sort of packet filtering feature, and there are many strong aftermarket products for personal firewalls. These software firewalls have the major advantages of always being present and working on all types of network connections from dialup to wireless. Many of them have centralized logging features that can be used to detect hacking activity directed against a specific user. As most administrators can attest, without proper logging, here is really no way to know when the host client was compromised. While there are some excellent SOHO firewalls available, many of the products on the market do not offer adequate security. Similarly, home firewalls installed by employees will vary widely in quality. The difficulty for a company deploying hardware firewalls in employee homes is in determining if all of the devices placed behind the firewall are trustworthy. Corporate security will be breached as soon as a second VPN or wireless network is plugged in behind the SOHO firewall. Worse yet, viruses may easily spread between home computers and onto the corporate network. Given these risks, the simplest and most effective solution is to require all corporate resources to be configured with appropriate firewall and virus software, and to treat all home networks as part of the hostile Internet. Wireless networks are an even more extreme example, as all network information is being broadcast. By adding a high-gain antenna, an attacker can easily connect to a laptop a mile away. Current versions of the Wired Equivalence Protocol (WEP) used to secure wireless connections are relatively easy to break. Even when encryption is used on a wireless link, attackers may be able to extract useful information by analyzing network traffic. It is trivial to match the wireless card last used in the executive conference room to the card currently being used in the local Starbucks. The best available solution to the problems of networking on shared media is to accompany host firewalls with VPN software that uses strong encryption, authentication, and integrity checking. Stronger authentication should be required access from public networks or for broad access to the internal network.
19
VSI Alliance (IPPWP3 1.0) VPN software should be configured to ensure that all packets leaving the client are routed through the corporate network. This is inconvenient for the employee who wants to print a document from work on their local network printer. However it will ensure that no breach of security occurs when a company employee and a spouse are both connected to their home network and are both using VPN connections to their respective employer networks. Email Encryption Email is constantly used for sending documents between companies. While the issue of securing internal email and storage was covered above, the security of inter-company email as a transport layer must also be addressed.One common practice is to encrypt the message using PGP, encrypted zip files, or other encryption programs. The encryption on zip files and many of the email encryption programs are easily broken, so this additional complexity actually accomplishes nothing. PGP is quite secure, but many people are unfamiliar with its workings. Without training and practice, PGP is likely to cause a false sense of security and be misused in practice. S/MIME can be much less prone to errors if all parties involved are using an S/MIME-capable email program, users have been distributed x.509 digital certificates, and the IT groups from both companies can co-ordinate to enforce proper use of encryption. However, this rarely happens in practice. Despite the limitations of S/MIME and PGP, they do provide end-to-end security. The message is secured from the senders desktop, over the internal network and the Internet, and so-forth, until it can be decrypted on the final workstation. When this level of end-to-end insurance is required, there is no substitute for training and one of the strong public key encryption programs. By far the simplest way to guarantee secure email between corporate partners is to set up a VPN between mail servers or to configure both mail servers to use the TLS encryption standard for SMTP mail. StartTLS can be installed on a Sendmail or MS Exchange server in a matter of minutes. After a few more minutes of testing, administrators can be sure that mail sent between these servers will be encrypted. Note that StartTLS does not guarantee end-to-end security. Mail is observable on internal networks, or if employees intentionally route mail through a third-party SMTP server. Levels of Transport Security Because remote network access is by definition an extension of the corporate network, it rarely makes security sense to provide different levels of transport for different employees. (There may, however, be excellent arguments based on technical, political, or budgetary requirements that dictate limited distribution of remote access.) Once connected to the network, all employees are restricted by the host and network level protections of the internal network. Instead, it makes sense to standardize one set of remote access methods that is easily audited and can be used by any employee that requires remote access. Thus, the levels of transport security are more appropriate for an organizations security requirements, rather than a given employees. Transport security can be broken down by acceptable risk from no transport level security (level 1) to requiring remote access to have a firewalled environment that matches the corporate network (level 4).
20
VSI Alliance (IPPWP3 1.0) The following table gives an example of possible transport layer classification types and encryption requirements for a chip manufacturer.
Table 6: Layers of Transport Security
Levels of Transport security
LEVEL 1 DESCRIPTION No transport layer security, trust that nobody will notice your traffic. Use of minimal transport layer encryption ENCRYPTION TYPES Remote access via webmail, or remote desktop software Plaintext inter-company email Easily available VPN encryption Encrypted email for sensitive documents between companies Operating system packet filters to protect OS 3 Remote VPN access IPSec VPN configured to restrict routing. Personal firewall software configured to log to central database Mail servers configured to use SSL or partner VPNs where desirable. 4 Remote access from SOHO offices only Hardware SOHO firewalls filtering on MAC address & providing point-to-point VPN to corporate network All email sent through central mail servers which require SSL or VPN to partner network Personal firewall software configured to log to central database PPTP with RADIUS accounts, SSH or SSL port forwarding PGP Microsoft, IPtables N/A EXAMPLE TOOLS
PGP, Cisco, IRE BlackIce, ZoneAlarm Exchange, Sendmail Cisco, Ravlin, SonicWall
Exchange, Sendmail
BlackIce, ZoneAlarm
21
22
Summary
Protecting IP is a step-by-step procedure, with steps ranging 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 this with security best practices. Below is a sample diagram that combines many of the technical measures and best practices described in this paper. First, notice the separation of subnets (networks) based on security levels, where level 4 contains developer data (IP), and level 1 is regarded as public information. In addition, notice how the authentication level increases with the security level, from userID and password (level 1) to userID and password, encrypted authentication, and hardware token (level 4). Furthermore, there are the three different classifications for remote or external access to the network, from the home user to the partner networks. Home users are required to use a VPN (IPSec protocol), host-based firewall, and a one-time password. Branch offices require only the use of a VPN and source IP authentication. Note that security level 3 and level 4 users are required to use storage encryption on the disk, whereas security level 1 and level 2 are not required to do so. Security levels 1 and 2 do not have any interaction with IP, so there is no need to implement security controls that would be classified as overkill. However, security levels 3 and 4 probably have interaction with IP on a daily basis; therefore, any data classified in that level not only needs to be protected with multi-factor authentication, but also disk encryption of stored data. As a result, the following table incorporates many of the security practices described above and maintains a strong, scalable, and dependable network, which is the key to business continuity and functionality.
23
Mail is sent over VPN; Legal protections used for storage of information
Partner Network
Branch Office
Devstore Level 4
Sec VPN Software Firewall, One-time password
Internet
Restricted by IP address, fixed VPN; All mail goes through HQ Mail server
Corporate Firewall
Security Level 1 (Soon to be public)
Security Level 2 (Confidential)
Restricted by User ID Artwork Department HR data
Restricted by IP address, User ID; encryption required
Mail server
Security Level 4 (Proprietary, Strategic) Encrypted disk, VPN encrypted access, virus checking, smartcard authentication
Security Level 3 (Proprietary) Encrypted disk, software firewall, virus checking, smartcard Developer Laptop
Figure 10: Example of Best Practices for Protecting IP
24
Appendixes
About the Authors
Himanshu Dwivedi (hdwivedi@stake.com) Himanshu Dwivedi is a Managing Security Architect at @stake with 7 years experience in information technology. His professional experience includes application programming and security consulting, with an emphasis on secure network architecture and server risk assessment of Windows and UNIX. Additionally, Himanshu has experience in mainframe environments, including the OS/390, specifically, security involving RACF and ACF2. At @stake, he forms part of the San Francisco-based Professional Services Organization (PSO) providing clients with attack & penetration services, secure network design, and secure server analysis. Himanshu is also part of the @stake Academy, where he is a lead instructor in several security classes, including Cyber Attacks and Countermeasures, Windows 2000 Security, and SAN Security. Himanshu has a wide spectrum of well diversified security skills, including various operating systems (Microsoft NT/2000, Linux RedHat/Caldera, OpenBSD), firewalls (Checkpoint Firewall-1, ipfilter, ipchains), Intrustion Detection Systems (ISS, Tripwire, Snort, and so on), Mainframe (OS/390), SANs (Brocade, Qlogic, Fibre Channel, and so on) and various other products and technologies. Himanshu is considered an industry expert in the area of SAN security, specifically Fibre Channel Security. He has given numerous presentations and workshops regarding the security in SANs, including TechTarget, the Fibre Channel Conference, SAN-West, SAN-East, and so on. Himanshu is currently in the process of releasing another White paper on Fibre Channel Security as it relates to SAN topologies. Robert Helt (robert_helt@msn.com) Rob Helt has over 20 years of sales and marketing experience in data networking and digital security. He has successfully led the Western Area sales teams for IBMs Global Network Services, AT&Ts Managed Network Services and, @stake, a digital security consulting company. He has worked with companies of all sizes, helping them assess and implement IT services and technologies, including outsourcing, hosting, VPN and remote access options, and consulting services that will most effectively support their business applications. He is a graduate of the University of Michigan. Myles Conley (mconley@stake.com) Myles Conley has been working in the network security field for the last 8 years. His work history incorporates experience in managerial, technical and training roles. He has held the senior security position at drugstore.com and Adobe Systems, creating and directing security policy for these dynamic environments while building advanced security infrastructure for cutting edge e-commerce. Myles was a senior security consultant at Secure Computing, one of the first pen-test to policy security consulting teams. Prior projects include a white paper on secure middleware, designing a private remote access system for 35,000 users, and writing security policies for commercial and academic environments. His hobbies include projects in digital radio and wireless networking technology for the third world.
25
26
Bibliography
BBC News Online, the Internet Arm of the British Broadcasting Corporation (BBC), www.bbc.co.uk C/Net News.com, C/net Networks, Inc., www.cnet.com CERT, www.cert.org Computer Security Institute (CSI), www.gocsi.com Computer Security Institute/FBI Survey, www.gocsi.com/press/20020407.html Crume, Jeff, Inside Internet Security. Copyright in 2000 by Pearson Education Limited. ISBN 0-201-67516-1. Hack-Proofing Your Network. Copyright in 2000 by Syngress Publishing, Inc. ISBN 1928994-15-6 Nichols, Randall K., Ryan, Daniel J. and Ryan, Julie J.C.H., Defending Your Digital Assets. Copyright in 2000 by The McGraw-Hill Companies, Inc. ISBN0-07-213024-5 Secure Business Quarterly, www.sbq.com System Administration, Networking and Security (SANS) Institute, www.sans.org Wired News, Wired Digital, Inc., www.wired.com
27
28
Glossary
Access Control List (ACL) A compilation of users, IDs, application programs, authorization levels and access types to which each individual or application is authorized to access and use. Often found in routers. Authentication The process of ensuring the identity of a connecting user or application program to a network or application. Process for determining that a user is who s/he claims to be. Authorization Access privileges granted to a user, application program or process. BIOS An acronym for Basis Input/Output System. The fundamental component of a personal computer that controls the way data is read from and written to memory, disk storage devices, keyboards and other peripheral devices. CERT - Computer Emergency Response Team Certificate An electronic document attached to a public key by a trusted third party that provides proof that the key belongs to a legitimate owner or authorized user and has not been compromised. Citrix A company in Ft. Lauderdale, Florida that is a leader in remote and virtual office software solutions used for access to networks, systems and applications. E4M A company in Canoga Park, California that is a leader in providing electronic forms (or e4ms). Encryption A set of mathematically expressed rules that render data transferred over a network unintelligible by executing a series of conversions controlled by a key. Firewall A device that controls the type of network traffic that flows in and out of a network. It is installed at the point of entry or connection to a network. Access through a firewall is permitted or blocked by policies or rules defined in the firewall by the manager of the device. FTP An abbreviation for File Transfer Protocol. A method for transferring files from one computer to another over network connections defined by the Internet Protocol (IP). IMAP An acronym for Internet Message Access Protocol. Intrusion Detection Systems (IDS) Hardware or software that collects data from a variety of network sources and systems and analyses the data to determine if any session or use may indicate a security problem. IP Intellectual Property IPSEC An abbreviation for Internet Protocol Security. An encryption algorithm that enables a secure tunnel, or communications link to be opened between a user and the network or application s/he is accessing. ISAKMP An acronym for Internet Security Association and Key Management Protocol. Defines procedures and packet formats for establishing, negotiating, modifying and deleting security associations. Formats that provide a consistent framework for transferring keys and authentication data independently of the key generation techniques and encryption algorithms on devices that generate keys for encrypting sessions.
29
VSI Alliance (IPPWP3 1.0) Kerberos An encryption protocol developed at MIT that serves to authenticate user access to a network or application. Key A sequence of symbols that when used with a cryptographic algorithm enables encryption and decryption. Usually a sequence of random bits used to establish a session between authorized users or applications. NTLM A Lan Manager (LM) authentication process used by Microsoft in its Windows NT/ 2000 operating system. PGP An acronym for Pretty Good Privacy. An email encryption protocol. PPTP An acronym for Point-to-Point Tunneling Protocol. A proprietary tunneling protocol from Microsoft that encrypts sessions between a user and the network or application s/he is accessing. RADIUS A protocol developed by Livingston Enterprises that is used in some Cisco servers to authenticate, authorize and account for user access. SANS - System Administration, Networking and Security. S/MIME An acronym for Secure Multipurpose Internet Mail Extensions. A standard that lets a user securely transfer non-textual data, such as graphs, during a remote session. SOHO An acronym for small office, home office. Usually, employees who work off-site, or remotely, from the company and need communications access the companys networks, systems or applications, using a computer or terminal. Access options may include dial-up (modem), DSL, frame relay, or dedicated line. SSH A registered trademark of SSH Communications and is referred to as Secure Shell, which is also a trademark of SSH. It is a defacto standard for remote access logons that is designed to prevent the capture of passwords by unauthorized users during an initial login. Telnet A virtual terminal protocol that enables remote users to logon to applications residing on networks. TLS An acronym for Transport Layer Security. A software-based security protocol that provides source authentication, as well as integrity and confidentiality of transported data. Token A hardware device or software program that generates a one-time password to authenticate a user for access. VPN An acronym for Virtual Private Network. Encryption used to separate users on a public network.
30

Vsia Ip Protection Measurements

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Vsia Ip Protection Measurements

Uploaded by

Copyright:

Available Formats

VSI AllianceTM White Paper Technical Measures and Best Practices for Securing Proprietary Information Version 1.

Issued by the Intellectual Property Protection Development Working Group

VSI Alliance (IPPWP3 1.0)

VSI Alliance (IPPWP3 1.0)

VSI Alliance (IPPWP3 1.0)

VSI Alliance (IPPWP3 1.0)

VSI Alliance (IPPWP3 1.0)

Intellectual Property Protection Development Working Group

Current DWG Member Representatives

VSI Alliance (IPPWP3 1.0)

VSI Alliance (IPPWP3 1.0)

VSI Alliance (IPPWP3 1.0)

VSI Alliance (IPPWP3 1.0)

VSI Alliance (IPPWP3 1.0)

VSI Alliance (IPPWP3 1.0)

Finding the Right Level of Security

BBC News, October 30, 2000: http://news.bbc.co.uk/hi/english/business/newsid_998000/998449.stm 2

VSI Alliance (IPPWP3 1.0)

VSI Alliance (IPPWP3 1.0)

VSI Alliance (IPPWP3 1.0) Internal

Operating system security

Operating system security, firewall rulesets and router ACLs

Username and password, public/private key authentication, hardware tokens

Figure 1: IP Filters in Windows 2000

2. SSH public key sent

3. SSH public successfully matched

Holds SSH Public and Private keys

Holds SSH Public keys

Figure 2: Graphical Representation of SSH (Secure Shell)

VSI Alliance (IPPWP3 1.0)

VSI Alliance (IPPWP3 1.0) External

VSI Alliance (IPPWP3 1.0)

Username and password

IT department, management network, sensitive subnets

Executive positions and financial departments

IP departments/engineers working on chip design

VSI Alliance (IPPWP3 1.0)

Encryption of data in shared file systems Encrypted databases

PGP, E4M Protegrity, Oracle 9i

Core source code for all products

Figure 3: EM4 File System Encryption - Example 1

Figure 4: EM4 File System Encryption - Example 2

Figure 5: EM4 File System Encryption - Example 3

Figure 6: PGP Encryption - Example 1

VSI Alliance (IPPWP3 1.0)

Figure 7: PGP Encryption - Example 2

PGP encrypts the individual file.

Figure 8: PGP Encryption - Example 3

The encrypted file is created.

VSI Alliance (IPPWP3 1.0)

Figure 9: PGP Encryption - Example 4

VSI Alliance (IPPWP3 1.0)

VSI Alliance (IPPWP3 1.0)

VSI Alliance (IPPWP3 1.0)

VSI Alliance (IPPWP3 1.0)

Sec VPN Software Firewall, One-time password

Security Level 1 (Soon to be public)

Security Level 2 (Confidential)

Restricted by User ID Artwork Department HR data

Restricted by IP address, User ID; encryption required

Figure 10: Example of Best Practices for Protecting IP

VSI Alliance (IPPWP3 1.0)

VSI Alliance (IPPWP3 1.0)