When Do You Need Information Systems Security Policies?
“Timing is everything.” This is most likely the No. 1 tenet of comedians. The same applies to the timeliness of policies. Why implement a policy on milking cows when your business model raises chickens? The possibility exists that your farm will expand operations one day, but there is no reason to write policies until that expansion occurs.
There will be times when the need for an ISS policy is evident. There is always a need for foundational security policies. This includes defining basic data handling and acceptable use policies. Security policies need to ensure that new technology is not introduced without a supporting set of policies in place. Another consideration is that you may have a process that occurs daily and all the involved employees are aware of that process. The employees may modify the process. But without configuration management control, modifications can make secure systems nonsecure. Or an important process may be undocumented, even though employees know all the steps. This is the perfect opportunity to formalize a written procedure.
Business Process Reengineering (BPR)
Business processes are constantly under scrutiny for improvement. As that business process life cycle is accomplished, the process is improved and changed; however, the associated policies must also be changed and updated. Typically, the associated policies and procedures recognized during the life cycle are operational in nature. Policies that support operations, like security policies, are not always considered. Failing to update those policies and procedures leaves a window of opportunity for error or disaster.
The process change could be dramatic enough to introduce new security vulnerabilities. If the equipment operating within the process completely changes, old security vulnerabilities reappear. Therefore, it is imperative to ensure that when reengineering any business process, you also review security. This will ensure that business process reengineering (BPR) includes ISS concerns, and those policies and procedures are updated as needed.
FIGURE 1-7 shows the four phases of BPR. Phase 1 is the planning phase. Phase 2 sees the creation or modification of the process baseline. Research and benchmarking happen in Phase 3. Phase 4 develops the future process; it is during this phase that new policies are written or current ones are updated.
FIGURE 1-7 Basic business process reengineering.
Continuous Improvement
You can view continuous improvement as finding a better way or as a lesson learned. As employees find new ways to improve a system or process, you need to have a way to capture their ideas. The concept of continuous improvement applies to all aspects of ISS and IA. For example, when looking at availability issues, you may come across an authentication weakness. Regardless of how the weakness or risk was found, you need to capture the information, assess the importance, and apply an improvement. Often, lessons learned flow from effective governance. Quality control will reflect what worked well and what didn’t. The part that didn’t work well represents the lessons learned. Sometimes this means changing policy. When policy goals cannot be achieved, enforcement becomes impossible, and the overall security policy framework is weakened.
The driver for “finding a better way” should not be a system crash or breach. In those cases, you may have to deal with lessons learned from the incident. Think of continuous improvement as a suggestion box. Employees identify needed changes and write a suggestion. The suggestion is either accepted or rejected. If accepted, it enters the formal reengineering process.
Making Changes in Response to Problems
Even with a sound policy framework, issues will occur. Depending on the criticality of the issue, policy implementation or change can occur at any time in the process. Policy changes brought about in this manner help avoid future incidents. In a perfect environment, policies fall into place before incidents occur; however, most organizations do not operate in a perfect environment. Once an event not covered by a policy occurs, an event analysis takes place, and a recommendation is drafted. For events that are noncritical in nature, policy drafting comes about in concert with the remediation process. If it is more critical in nature, remediation should occur prior to writing the policy.