Internet Security: A Jumpstart for Systems Administrators and IT Managers
ISBN: 1555582982
EAN: 2147483647
EAN: 2147483647
Year: 2003
Pages: 103
Pages: 103
Authors: Tim Speed, Juanita Ellis
|
This is an area where many companies fall short of the mark. Check your environment to see if you have any existing security plans, policies, and/or procedures. These can include physical security, LAN security, Internet access, and even disaster recovery. At this point, you have decided which threats pose an unacceptable risk to your computing environment and what level of action you are willing to take to defend against them. Studying the security plans that your company has and their implementation may help you decide which security measures are most important for your environment. One of the most important parts of this review is the identification of policy compliance. Policies are only good if they are implemented; a thorough implementation plan is required. Part of your security implementation plan should be a review of any existing policies that concern security.
Policy goals and objectives
Scope
Responsibilities
Physical security
Network security
Data classification (data categorization)
Access control
Password change and enforcement policies and procedures
Incident handling procedures
Acceptable use policies
Change control
Training
Compliance
Define what you are trying to accomplish with your policies. The objective defines your approach to Internet security. These approaches could include the use of tools, systems, and employee/user training.
The scope specifies the assets that will be protected by security policy. The scope could define a specific policy or a body of policies. The scope should include who is impacted by the policy: end-users, employees, customers, vendors, and so on.
The responsibilities section of the policy document describes how the individuals defined in the scope section will be responsible for the security of your environment. Detail the security responsibilities as needed by region, department, or groups. Depending on the company size, responsibility may be assigned to the following personnel.
The top directors the CxOs are responsible for high-level security strategy and must make the necessary resources available to combat security threats to the business.
The security manager is responsible for the entire enterprise security. The security manager defines the enterprise security policies and procedures and works with the business managers to implement the initial risk analyses as well as the individual process risk analysis. The security manager implements each facet of security, such as:
Secure network
Security applications
Auditing
Incident handling
Facilitation of legal reviews of the various security issues
The process owner is directly responsible for a particular business process and can be a department manager, a lead engineer, a specification custodian, or any employee tasked with accountability for a business system. The process owner will work with the security manager to analyze risks and recommend the countermeasures for each process. The process owner may not have extensive experience with security, so the recommendation may be at a business level only. For example, the process owner will say, "We need to limit access to this application to a single group." The security manager hears, "Access control will need to be set up and implemented for applicable personnel in the process group via the corporate policies and procedures."
The legal department needs to be involved with the design of the security policies and procedures from day one. Make sure the following issues/items are covered within each policy.
Guidelines for acceptable use
Ethics, for users and administrators
Access by customers, including liability and damages, performance, and compliance
Risk and exposures in the event that business data is compromised
Analysis of communications sent to customers in the event of a security event (e.g., hackers, data compromised)
Auditing and use of logs for evidence
Copyright issues
Use of electronic signatures and encryption
Management of unauthorized access
Review of any agreements with Extranet vendors, customers, and ISPs
Interpretation of the Uniform Commercial code in relation to business use of the Web for your particular business (http://gopher.law.cornell.edu/).
The developers define the responsibilities of the application developers. Security needs to be built into the application from day one of the development cycle.
The users are responsible for security in the enterprise as much as the CxOs. Every user needs to be trained on the company security policy, data categorization, and system procedures as well as understand what the consequences of their actions are and how to act accordingly.
The auditors should be familiar with but independent of the activities performed by the organization or group being audited. They will perform audits specific to requirements in the security policies and procedures.
Physical security measures must provide for the protection and access to the physical assets of the business (e.g., servers and applications). The physical security document should describe how the various assets are to be protected (such as locked server rooms, card readers with limited access, or logging systems to track who has access to each type of server).
The network security document describes how you will protect assets stored on the network. This document could include security steps on the following.
Network access
Use of sniffers
Access to Internet services
Methods of DOS attacks
Every business possesses data that is owned by someone. The value of this data can vary from one application to another, from one business to another, and even from one competitor to another. Business data should be classified based on the security requirements of that data. A data classification policy document should describe the requirements to classify the data. Do not confuse the classification of data and the service level of that data. You can have data that is open to the public, but if the public cannot read the data due to a DoS attack, then that data is useless no matter what your classification is.
Following are examples of data classifications.
This data/information is available to the public. Access to this data by competitors is acceptable and does not represent a threat to the business.
This data is available only to approved vendors and/or business partners. Access to this data by competitors can pose a risk to the business. Access to this data must be logged and restricted.
External access to this data is restricted. Access to this data by competitors or the general public could put the business at risk or cause embarrassment. Access to data is restricted to internal employees only and access will be logged.
This data is confidential within the company and protected from external access. Access to this data can give competitors an advantage in the marketplace. Access will be limited to select employees and groups. All access will be logged. Backup tapes will be controlled.
This data will not be placed onto any networked systems. Access will be limited to very select individuals and all access will be logged and monitored. If this data is compromised, the business can be at risk.
Depending on the application and the data, users may need to be authorized. Define your requirements in this section of the document. Define the access to the authoritative directory for this authentication, and include the following access control features as needed.
Users should be prevented from deleting other users' files in shared directories.
Users should be able to manage the privileges of data elements that they own.
Access control should be linked into data classifications.
| Note | Not all authentications will necessarily be from an authoritative directory. |
Be careful with this section of the document. Not all applications or operating systems have the same password management systems or rules. You may need several documents to cover each type of password management. Also, consider using a single sign-on system, which can help manage passwords and the password rules. Consider the following examples when setting up your policy document.
Set up password rules to prevent "crackable" passwords
Require a combination of numbers, upperand lowercase letters, and punctuation.
Use a password that you can remember without having to write it down.
Use short passwords.
Create some guidelines for users on how to manage their passwords
Do not share or give your passwords to others. Do not allow others to tailgate into applications using your password.
Do not write down the password or send it to someone via e-mail.
Do not create a single administration user name and password that will be shared between several administrators (this compromises the ability to audit).
If possible, set up an administration account and password separate from the administrator's personal account. For example, your messaging administrator, Joe Smith, will be assigned two accounts: Joe Smith and Joe SmithAdmin, each with its own password. Additionally, the privileges will not be the same. The Joe Smith account will have the standard user access privileges that a typical user will have. The administrator will send all e-mail via this account, and will access any applications from this account. If the administrator needs to make any changes to the environment, he would then use the Joe SmithAdmin account. This account will provide the needed level of access to administer the environment. Joe will not use the Joe SmithAdmin account to send e-mail or to use any applications.
Educate users about the dangers of password hacking/cracking.
Encrypt passwords within the directory.
Define the age expiration limit of the passwords and management and tracking of password history.
Define the encryption strength.
Define the mechanism and systems to track and stop directory attacks.
Define the use of smart cards, tokens, and biometrics.
An incident is an unplanned, unexpected event that requires immediate action to prevent a loss of business, assets, or public confidence. All policies must have an incident handling component plus a feedback component. The feedback loop is the mechanism that will keep the policies current and updated. An incident handling process is critical to permit continuity of important business processes in the event of an incident and allow the business to function. Service levels will be needed to determine what level of handling is needed based on each incident type. An incident where the web site is down and the business cannot conduct electronic transactions will generate a different response than a situation where a user may have lost an e-mail message.
The response team should include representation from these individuals.
Management
Technical personnel
Legal counsel
Team coordinators
Communication specialists
Be sure to define the basic procedures for handling an incident. In case of an incident, each of the following points should be implemented.
Preparation. The team should have a charter.
Incident detection. The processes and tools to detect an incident should be in place.
Immediate action. This needs to be prioritized based on a scale of importance (more in Chapter 11).
Communications. This is critical to handling an incident.
Detailed situation analysis. Observe and report what happened.
Recovery. Get the business running again.
Feedback. How can we keep this from happening again?
Following are some general guidelines to help you set up and manage your incident response team.
Take a look at http://www.cert.org/nav/recovering.htm.
Create a hard-copy list of contact names, telephone numbers, and e-mail addresses.
Test the processing on a regular basis.
Test your backups.
Test your communication process.
The acceptable use policy section states how users will be allowed to use network resources. There should be several policies created.
Acceptable use for e-mail
Acceptable use for network access
Acceptable use for data disclosures
Some people may argue that change control is not a security concern, but without adequate change control, a site can crash without warning. Hence, our future discussions will address change control as a security concern. Just a simple change can impact the infrastructure and/or application. A concrete check for this is, "Does the site have a change control system and/or policy in place?"
End-user training if very important. A successful security program will include various training methods. These can include:
Classroom training
Frequently Asked Questions (FAQs) documentation
An Internal Web page (Intranet) shows
Current Bugs
Virus information
Corporate Security policies
FAQs
An educated user is an important weapon in keeping your environment secure.
The Compliance section of your security policy will show how you maintain your security. Compliance can include:
Audit procedures
User training schedules
Vendor use, via audits, of corporate resources.
Most companies also include an employee compliance application. This application is used to track when employee read and agree to the corporate security policies. Most companies required employees 'certify' themselves every year.
|