Physical and Environmental Safety

Physical and Environmental Safety
Physical and environmental safety controls are developed and implemented to protect the physical facility housing employees, data, and equipment. An organization's physical and environmental policies should address at least the following topic areas:

>Access Controls. Physical access controls restrict the entry and exit of personnel, equipment, and media from an area. The granularity of access controls should be commensurate with the value of the items located in that area. For example, there should be very limited access to servers and cabling. Anyone exiting an office area carrying equipment or media must provide appropriate approvals. Physical access controls should address not only the area containing system hardware but also locations of cabling used to connect elements of the system, supporting services such as electric power, backup media, and any other elements required for the system's operation. It is important to assess the effectiveness of physical access controls in each area, during normal business hours, and at other times, particularly when an area may be unoccupied or occupied by maintenance employees.

Fire Safety Factors. Fires are a significant threat because of the potential for complete destruction of both hardware and data, the risk to human life, and the pervasiveness of the damage. Smoke, toxic gases, and heat from a fire can destroy lives and critical data and damage systems throughout an entire building or business campus. Consequently, in addition to the annual local fire marshal inspection, it is important to evaluate the fire safety of buildings. It is a solid business practice to have fire safety as part of the company's audit program.

Utilities Failures. Systems and the people who operate them have an expectation of a well-regulated operating environment. Consequently, failures of electric power, heating, and air-conditioning systems; water; sewage; and other utilities usually cause service interruptions damaging hardware and data, making working conditions unbearable. Organizations should take every precaution to ensure that utilities function properly, and in the event of failures, the organization must make certain there are redundant systems available to continue profitable operations. Risk planning will consider the degree of redundant utility systems and how long they should be available.

Building Collapse. Organizations should be aware that a building might be subjected to loads greater than it was designed to support. This results from earthquakes, snowfalls, or explosions that displace or weaken structural members, or a fire that destroys structural supports.

Plumbing Leaks. Water leaks do not occur frequently, but when they happen they can be very disruptive. An organization should know the location of water pipes that might leak or burst, endangering employees and equipment. Businesses should take appropriate steps to reduce risks by relocating pipes and fire extinguishing equipment and clearly identify shut-off valves.

Workplace Safety. Employees must be safe in the workplace. Laws, regulations, and policies demand it. Auditors and managers should frequently assess workplace safety by walking around and looking for cables crossing walk areas, unsafe equipment placement, lack of safety equipment in areas such as loading docks, overloaded electrical connectors, unsafe elevators, etc.

Appropriate and adequate controls will vary depending on the individual system requirements. The following list shows the types of controls for a system in a computer room. It is not intended to be all-inclusive or to imply that all systems should have all the controls listed.

- Card keys for building and work area entrances

- Twenty-four hour guards at all entrances and exits

- Cipher lock on computer room door

- Dedicated heating/ventilation/air conditioning system

- Humidifier, if appropriate

- Emergency lighting

- Fire extinguishers rated for electrical fires

- B/C-rated fire extinguishers

- Smoke, water, and heat detectors

- Emergency power-off switches

- Surge suppressors

- Emergency replacement equipment

- Zoned dry-pipe sprinkler system

- Uninterruptible power supplies for critical equipment

- Power strips and power suppressors for peripherals and computers

- Separate controlled access to server and cabling rooms

- Protection for water-sensitive equipment in the event of fire

Systems Development Lifecycle (SDLC)

The SDLC is a mechanism assuring that systems meet established requirements and further the organization's business strategic goals. It provides a structured approach to managing projects, beginning with the justification for initiating development or maintenance efforts and concluding with system disposal.

Most organizations spend millions of dollars annually in the acquisition, design, development, implementation, and maintenance of information systems. The need for secure and reliable system solutions is easily recognized by the dependence on computer systems needed to provide products and administer daily activities.

SDLC methodology establishes policies, procedures, and guidelines managing project development, planning, requirements analysis, design, development, integration and test, implementation, and operations, maintenance, and disposition of information systems. The SDLC is not the do-all, be-all, end-all methodology. There are many permutations of it, but those concepts will not be addressed in this section. However, SDLC is one development method that has a proven track record and should be integrated with already-existing organization policies and procedures.

SDLC Benefits

Reduced risk of project failure

Consideration of user requirements throughout the system's lifetime

Early identification of technical, performance, and management issues

Description and disclosure of all costs guiding business decisions

Realistic user expectations of what the system will deliver

Identification of systems and processes that are no longer cost effective

Measurements of project progress to enable necessary corrections

Supports effective resource and budget planning and accountability

Identifies current and future business requirements

SDLC Supports the Use of an Integrated Product Team
The SDLC project team can provide for the project's success. It should be an interdisciplinary group composed of a senior management project sponsor, a project manager, and team members responsible for planning, implementation, and delivery. Team members should comprise senior employees representing business units such as user groups, human resources, program/functional management, quality assurance, security, legal, telecommunications, data administration, database administration, logistics, financial, systems engineering, test and evaluation, contracts management, audit, physical facilities, and configuration management. Working together in a proactive, open-communication, team-oriented environment can build a successful project by providing decision makers with the necessary experience and information to make the right decisions at the right time.

The SDLC has nine phases or steps that will be briefly described:

SDLC System Concept Development Phase. This project concept initiates the development lifecycle. It begins when a business need, based on operational requirements, is identified. Once the operational requirement is expressed, the approaches for meeting it are reviewed for necessity, feasibility, reasonableness, and appropriateness. The need may involve development of a new product or the modification of an existing system. Senior managers are usually the responsible officials for approvals and funding before the planning phase can begin.

Planning Phase. A program plan is developed documenting the approach to be used, including the formulation of methods, tools, resources, schedules, user input, funding, audit, and risk management.

Requirements Analysis Phase. User requirements are formally defined along with the requirements of system performance, data, risk management, and maintenance. All requirements are detailed to such a level that it is sufficient for designers to proceed.

Design Phase. The external characteristics of the system are designed during this phase. Operating environments are established, major sub-systems with their required inputs and outputs are defined. At this time, processes are allocated to resources. User input is documented, reviewed, and modified, and final approval is made. Internal characteristics of the system are described, specified, and designed. Required logic specifications are prepared for software modules.

Development Phase. Detailed specifications produced during the design phase are translated into hardware, software, and communications links. Software is integrated, tested, modified if necessary, and retested.

Integration and Test Phase. System integration, risk management, and user acceptance are conducted during this phase. Users, audit, and quality assurance units validate the functional requirements, as defined in the functional requirements documentation. It is important that these functional requirements are satisfied by the developed system.

Implementation Phase. The systems are installed and made operational initially in a test environment. After successful testing, the system is made operational in a production environment. This phase continues until the system is operating in production in conformity with user requirements and design parameters. Its security is certified. In this phase, it is accepted or rejected by users.

Operations and Maintenance Phase. By now the system is operating and is monitored for continued performance, satisfying user requirements. If needed, system modifications proceed through a requirements and necessity phase; they are scheduled, designed, tested, and implemented. If more than relatively simple modifications or changes are identified, the system will reenter the planning phase.

Disposition Phase. Disposition activities ensure the orderly review, modification, and termination of the system. Emphasis is granted to the preservation of data processed by the system in order for data to be migrated to another system or stored in compliance with records management policies, laws, or regulations for future accessing and processing.

Management Controls
The SDLC requires the following comprehensive management controls:

Structured approach to systems development, operation, and disposal

A senior management sponsor, preferably someone with a cheerleader's enthusiasm

Project management limited to a single, accountable project manager

Comprehensive project planning required for each system project

Projects proceed when sufficient resource availability is assured

Organized and accessible documentation of all steps, decisions, deliberations, agreements, requirements, plans, proposals, schedules, risk management, security measures, quality controls, funding, auditing, and meetings

Documentation
The SDLC specifies that documentation shall be generated during each phase. The principal categories of documentation are divided into two types:

1. Process documentation details actions taken for developing, implementing, testing, and maintaining the system. Process documentation includes but is not necessarily limited to plans, notes, meeting minutes, deliberations, funding, schedules, charts, funding expenditures, auditing documents, quality control decisions, reports, and time and attendance reports.

2. Product documentation includes matters that detail the system itself, what it is, how it is operated, how it is maintained, and future disposal. Examples include but are not limited to technical manuals, user manuals, operations manuals, maintenance manuals, systems requirements documentation, and design documentation.

It should be noted that some documentation will remain relatively static throughout the system lifecycle and some will be continuously changed. Some documents are revised documenting the results of analyses performed during operations. Each document should be collected, stored securely, and protected for future reference. It is important that regulatory and legal issues are addressed before any documentation is destroyed. Undocumented or inadequate documentation of decisions and events can cause significant confusion or wasted efforts and can intensify the effect of team member turnover. Activities should not be considered complete, nor decisions made, until there is sufficient documentation of the activity or decision. In the case of some very large projects, there cannot be advancement to the next SDLC phase without the required audits, management reviews, and appropriate approvals.