Security policy and objectives

Defining what to protect and what to expect of users.

Your security policy

Start of changeEach Internet service that you use or provide poses risks to your iSeries™ system and the network to which it is connected. A security policy is a set of rules that apply to activities for the computer and communications resources that belong to an organization. These rules include areas such as physical security, personnel security, administrative security, and network security.End of change

Your security policy defines what you want to protect and what you expect of your system users. It provides a basis for security planning when you design new applications or expand your current network. It describes user responsibilities, such as protecting confidential information and creating nontrivial passwords. Your security policy should also describe how you will monitor the effectiveness of your security measures. Such monitoring helps you to determine whether someone may be attempting to circumvent your safeguards.

Start of changeTo develop your security policy, you must clearly define your security objectives. Once you create a security policy, you must take steps to put into effect the rules it contains. These steps include training employees and adding necessary software and hardware to enforce the rules. Also, when you make changes in your computing environment, you should update your security policy. This is to ensure that you discuss any new risks that your changes impose. You can find an example of a security policy for the JKL Toy Company in the Start of changeIBM® Systems Software Information CenterEnd of change in the "Basic system security and planning" topic.End of change

Your security objectives

When you create and carry out a security policy, you must have clear objectives. Security objectives fall into one or more of these categories:

Resource protection
Your resource protection scheme ensures that only authorized users can access objects on the system. The ability to secure all types of system resources is an iSeries strength. You should carefully define the different categories of users that can access your system. Also, you should define what access authorization you want to give these groups of users as part of creating your security policy.
Authentication
The assurance or verification that the resource (human or machine) at the other end of the session really is what it claims to be. Solid authentication defends a system against the security risk of impersonation, in which a sender or receiver uses a false identity to access a system. Traditionally, systems have used passwords and user names for authentication; digital certificates can provide a more secure method of authentication while offering other security benefits as well. When you link your system to a public network like the Internet, user authentication takes on new dimensions. An important difference between the Internet and your intranet is your ability to trust the identity of a user who signs on. Consequently, you should consider seriously the idea of using stronger authentication methods than traditional user name and password logon procedures provide. Authenticated users may have different types of permissions based on their authorization levels.
Authorization
Start of changeThe assurance that the person or computer at the other end of the session has permission to carry out the request. Authorization is the process of determining who or what can access system resources or perform certain activities on a system. Typically, authorization is performed in context of authentication. End of change
Integrity
The assurance that arriving information is the same as what was sent out. Understanding integrity requires you to understand the concepts of data integrity and system integrity.
  • Data integrity: Data is protected from unauthorized changes or tampering. Data integrity defends against the security risk of manipulation, in which someone intercepts and changes information to which he or she is not authorized. In addition to protecting data that is stored within your network, you may need additional security to ensure data integrity when data enters your system from untrusted sources. When data that enters your system comes from a public network, you may need security methods so that you can do the following:
    • Start of changeProtect the data from being "sniffed" and interpreted, typically by encrypting it.End of change
    • Ensure that the transmission has not been altered (data integrity).
    • Start of changeProve that the transmission occurred (nonrepudiation). In the future, you might need the electronic equivalent of registered or certified mail.End of change
  • System integrity: Your system provides consistent, expected results with expected performance. For the iSeries, system integrity is the most commonly overlooked component of security because it is a fundamental part of iSeries architecture. iSeries architecture, for example, makes it extremely difficult for a mischief-maker to imitate or change an operating system program when you use security level 40 or 50.
Start of changenonrepudiation End of change
Start of changenonrepudiation is proof that a transaction occurred, or that you sent or received a message. The use of digital certificates and public key cryptography to "sign" transactions, messages, and documents supports nonrepudiation. Both the sender and the receiver agree that the exchange took place. The digital signature on the data provides the necessary proof.End of change
Confidentiality
Start of changeThe assurance that sensitive information remains private and is not visible to an eavesdropper. Confidentiality is critical to total data security. Encrypting data by using digital certificates and the Secure Socket Layer (SSL) helps ensure confidentiality when transmitting data across untrusted networks. Your security policy should conclude how you will provide confidentiality for information within your network as well as when information leaves your network. End of change
Auditing security activities
Monitoring security-relevant events to provide a log of both successful and unsuccessful (denied) access. Successful access records tell you who is doing what on your systems. Unsuccessful (denied) access records tell you either that someone is attempting to break your security or that someone is having difficulty accessing your system.

Start of changeUnderstanding your security objectives helps you create a security policy that includes all your networking and Internet security needs. You may find it helpful to review the JKL Toy Company e-business scenario as you define your objectives and create your security policy. The scenario company's Internet usage and security plan is representative of many real world implementations. End of change

Related concepts
iSeries and Internet security considerations
The layered defense approach to security
Digital certificates
Secure Socket Layer (SSL)
Scenario: JKL Toy Company e-business plans