Tools are available on the market that can aid in policy formulation. Equally fundamental is proper implementation of new policies. This section considers the following topics:
- Useful policy tools
- Policy implementation
Useful Policy Tools
It is always beneficial to deconstruct an organization to get a thorough understanding of what might be required to protect both its equipment and personnel.
The advent of user-friendly policy development tools can aid organizations in the development of security polices, or the tools can simply serve as a basis for discussion, ensuring that a security committee has not overlooked significant areas. While a number of such tools are available on the market, one example is Information Security Policies Made Easy (http://www.informationshield.com/ispmemain.htm). The tools can prompt the policy formulators to describe the company network in the following terms:
- State the number of users
- State the type of equipment currently residing on the network
- Describe the password process in place
- State whether the company has a DMZ server
- List remote offices or other remote users
- State the type of remote access currently used, such as VPN
- State whether wireless technology is being used
- List external connections to partners
- State whether the company is using IP telephony
- Determine further pertinent questions to ascertain the current situation
After questions are answered, policies appropriate to the organization’s current posture are presented. The policies can be implemented, or a security steering committee could use them as tools to initiate pertinent discussion among committee members.
Policy Implementation
If a policy reflects a new technology, sufficient training must be conducted prior to implementation. For example, if a VPN is being installed, users require effective training prior to installation to avoid unnecessary downtime. Relevant IT staff must be pretrained as well.
Prior to a policy being formalized, offline testing should ensure that it fully addresses the situation for which it was created. White-hat hackers, which are independent auditors trained to look for vulnerabilities, can be used to perform an assessment of the test environment. They create a situation and then record how the process played out, asking the following questions:
- Did IT discover the white-hat hacking?
- How long did it take IT to realize the system was under attack?
- How far into the system did the white-hat hackers get before being noticed?
- Were the security holes plugged?
A report can quickly summarize areas that need to be addressed. For example, if certain staff members were not immediately notified of an attack, the report might highlight a number of potential issues, as follows:
- A file containing pertinent names and phone numbers is not readily available.
- CD-ROMs with OSs and patches are not readily available.
- Pertinent staff are not comfortable with the battle stations they are expected to assume when in crisis mode.
These items can be quickly remedied, but sometimes they need to be highlighted and rectified before wide-scale implementation.
The following additional processes are worth considering when developing policies:
- Maintain checks and balances For example, the individual responsible for unearthing irregularities in logs should not also have access, or modification rights, to data-sensitive files such as payroll, R&D, or finance.
- Limit access Users should not be granted any greater system or physical access than necessary to perform their jobs. Access should be granted on an as-needed basis and should be revoked when no longer required.
- Keep users abreast of changes If a new policy is implemented, but users are not fully informed, issues could result. For example, if a new policy states that passwords must change every 30 days but users are not informed, they will log on the 31st day and be unable to access their accounts without creating a new password. With notice, and an explanation of the policy, users can become active participants in the process, ensuring that they construct secure passwords as scheduled.
As another example, a new policy might dictate that backup tapes are stored by a third party, and through formal negotiation, it has been arranged that the tapes will be collected every morning at 9 a.m. But if reception personnel are not duly informed, they are unlikely to release the tapes to a courier.
PEOPLE FIND THIS PAGE BY THIS WORDS:
organisational tools and policies for IT security;
