ABSTRACT
Implementing a security policy is not an easy task. It requires careful planning and careful execution to ensure effectiveness. Once senior management has been brought onboard and understands the need for a more secure environment, policy planning can commence. Assuming that a preliminary risk assessment has already been carried out, it will need to be refined and documented. External risks and internal risks will need to be graded and classified by risk factor. An application inventory should be carried out to get a detailed definition of the operating environment. These details should be used as a guide for a supported applications directory for a corporate help desk, and also provide the necessary information to segregate these applications between user departments. The operating requirements of these applications can be used to effectively secure the applications properly by securing the necessary access rights by each individual department. Applications should be accessed based on departmental or group rights — not by individual rights. Although there will be cases in which this may not apply, it should be handled by the security policy. In any event, the application inventory will allow for a more secure internal operating environment by preventing abuse from within. Securing internal resources and servers will also be required and should be done in tandem with the application inventory. It will be necessary to capture the required rights and permissions to properly access and execute corporate applications and restrict unauthorized use by narrowing network access to these resources and applications. The introduction of auditing access to these network resources should also be defined and set up. Tracking access failures to these resources will provide intuitive insight into what is happening, and perhaps why. Breaches in security can be classified as either a true access violation or an apparent access violation. Auditing will help uncover these events. The fewer privileges available to a user, the less likely damage can be caused by the user, by either error or account breach. In essence, one needs to avoid the likelihood of a situation such as, “Oh, I wonder what
would happen if I ran this program, or click on this, etc.” Defining the project will require at least six fundamental stages of implementation (see Exhibit 1). Like any project, these stages depend on one’s environment and are only recommendations. A sample project plan is provided in Exhibit 2. It clearly defines each of the stages for a project, as well as the management support for the project.
