- Securing the Organization: Equipment and Access
- Managing the Availability and Integrity of Operations
- Implementing New Software and Privacy Concerns
- Regulating Interactivity Through Information and Equipment Control
- Mobilizing the Human Element: Creating a Secure Culture
- Creating Guidelines Through the Establishment of Procedural Requirements
- Determining Rules and Defining Compliance
- Securing the Future: Business Continuity Planning
- Ensuring a Successful Security Policy Approach
- Surveying IT Management
Creating Guidelines Through the Establishment of Procedural Requirements
The structure of security policies should not appreciably differ from other procedural documents an organization might construct. Policies should be formulated by a group consisting of security and company experts; the latter should comprise a cross section of senior managers who lead major departments within the organization. While Chapter 10 focuses on policy content, this abbreviated overview is concerned with fundamental structure. Specifically, every policy should attempt to answer the following questions:
What is the policy about, and how does it get accomplished?
Who owns the policy?
Every policy component should explicitly state what it is attempting to achieve. If a particular process uses technology to realize its goal, a short summary detailing the role of the equipment should be provided to enable the reader to garner its purpose. Equipment usually requires human intervention, and policies should detail all that is required of users to ensure proper use and compliance; the users need to know unequivocally what is expected of them, including the potential consequences for noncompliance.
Policies should contain defined review dates, ensuring that their core components are continually reevaluated and updated.
Every process needs an owner, an individual who is ultimately responsible for a function or job. Whether the process is equipment, networks, software, appliances, or databases, clearly defining roles and responsibilities can avoid the inevitability of postattack finger pointing.
The sales department, as an example, might believe that it owns the customer relationship management (CRM) software, and the engineering department might justifiably assume that it has responsibility for its highly specific plotter equipment. But the IT department likely has a different view of both situations. Should an attack be the result of improper loading or installation, which department would be at fault? Different levels of responsibility must be considered: Operators of the sales tool or engineering printer might not consider security their issue, but unless otherwise specified, owning either should entail complete accountability. To resolve this dilemma, an organization might declare two owners for specific situations: The user would be responsible for populating fields with data, and the IT department would be accountable for operability, ensuring that data is backed up every evening and that patches are applied as soon as they are published. This process would ensure that the equipment user is responsible for determining security classifications and secure handling of documents produced on the equipment, while IT is responsible for the security of the physical equipment itself.
Ownership is not about placing blame. Rather, it is concerned with assigning complete responsibility, ensuring that no individual or department can ever say, "I thought someone else was supposed to do it." Ownership defines accountability, and in so doing promotes a culture that is steeped in prevention and responsibility.