Employees Must Think before Clicking the Send Button: Is There an Undelete Button?

Just because e-mail is one of the quickest ways to communicate with others does not necessarily mean it is the most appropriate way to do business at all times. When you are training employees in the use of e-mail, there are some other important factors to consider.

Confidentiality
E-mail is not private. Messages that are sensitive or private must never be sent through e-mail. Employees should understand there are many persons who have legitimate access to their e-mail, not the least of which are senior managers, systems administrators, auditors, and sometimes investigators. Additionally, there are attackers who are illegitimately engaged in accessing e-mail accounts.

Negotiations
These exchanges are best conducted either face-to-face or through telephone conversations. Regardless of whether they are related to an employee's salary, contract negotiations, or the price of cabbage, dialogues of this nature are best held until the parties can discuss them verbally.

Bad News
Train all employees never to use e-mail to deliver bad news or to discuss performance-related or emotionally charged issues. Senior managers must thoroughly understand this principle. Without the benefit of facial expressions, vocal intonations, and body language, hurt feelings can result.


Plain, Professional Language
Obscenity, vulgarity, profanity, defamation, off-color remarks, and just plain nasty talk have no place at work or in e-mail. Electronic communications are not private and can be read by a variety of persons today and in the future. Plain, courteous, professional language is the language of business. Risks associated with this type of activity are extremely damaging to the organization and to the individual employee.


Attachments
Organizations must be cautious about sending and receiving e-mail attachments. Instruct employees to copy and paste items into the body of the e-mail. If it is not possible, the sender should ask the recipient if the item can be sent as an attachment. Employees should be cautious about opening attachments and they should be mindful that this is primary way that viruses are distributed. If the e-mail users are technically minded, train them so they recognize that attachments with extensions of .exe, .vbs, and .src should never be opened. Systems administrators should consider using software that denies executable attachments from being delivered to the organization's interior networks.

Spam
Instruct employees never to reply to unsolicited or unwanted e-mail, affectionately known as spam. Replies usually have the effect of confirming active e-mail accounts for spammers who may sell or trade viable e-mail accounts to other spammers, thereby compounding the problem. Irate replies usually go to empty e-mail accounts as spammers often use one-time e-mail addresses.

Message Priority
Do not indicate that your e-mail is urgent if it is not. Do not oversell e-mail messages. Reserve urgent notifications for those e-mails that are truly important.

Forwarded E-Mail
Instruct employees they must not forward e-mail, attachments, and the latest newsletters willy-nilly. They may find them interesting, but most recipients will not. Be respectful of your intended e-mail recipient's time. They may not be very excited about receiving the latest and greatest magazine articles about salad dressing.


Salutations and Signatures
Incorporating salutations and signatures into the text of an e-mail threat will establish the employee's role and position. An additional benefit is derived from using salutations and signatures: they provide beginnings and endings to messages attributable to specific individuals.

Spelling and Grammar
Instruct employees to use proper language construction, spelling, and grammar that distinguish professional conduct. Use spell-checking and grammar-checking software before sending e-mail. Avoid word and sentence constructions that have double meanings. Do not editorialize or rant in e-mail messages. Red herrings cost time and money. Employees should be frequently reminded that it is possible their messages will be introduced in a court of law.

Encrypted Communications
There are many ramifications of encrypted e-mail communications. Employees can exchange e-mail, assured of its integrity and confidentially. While this is certainly an advantage, it is easy to e-mail proprietary information to outside parties, using crypto-technology. E-mail encryption programs can be easily purchased and in some cases are free. If organizations are going to monitor e-mail communications, they are not going to be able to read encrypted messages. More than one employee has used the company's encrypted e-mail to send sensitive information to waiting competitors without fear of being caught.

E-Mail for Managers
Managers should remind employees that e-mail and the attendant systems are the property of the organization and are being monitored. Each time a manager reminds employees of this fact, it should be documented so it can be retrieved and formally acknowledged by employees. Human Resources units should have signed acknowledgments from all employees.

All employees are subject to the organization's policies. No one is outside this policy unless specifically and formally exempted. Exemptions must be justified and individually approved. Being a senior manager is not sufficient justification for an exemption. Managers and auditors must enforce the organization's e-mail policy consistently and equitably. Do not allow special rights to some employees that are not enjoyed by all employees.

Out-of-Band Communications
If communications are very sensitive, employees and managers particularly must know about out-of-band (OOB) communications. OOB communications are outside the regular communications channels. They may include conversations through cellular telephone calls outside the workplace, e-mail communications between computers outside the workplace, encrypted communications, etc. OOB communications alternatives should be available to employees with a reason to use them.

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:

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.

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.

System Accreditation and Certification
The accreditation process in the SDLC ensures that the system will operate within an acceptable threshold of risk, and complies with the system security policies and any legal and regulatory requirements. At the completion of each lifecycle phase, the accreditation manager (usually the senior manager responsible for accepting the system) reviews the certification results in the design documentation to determine if the system design should proceed to the next lifecycle phase or if the design should be altered to reduce risks. The decision to halt or progress will depend on the acceptability of identified risks and compliance of the system's design to the applicable policies.

System accreditation is the process forcing managers and technical staff to find the best risk management processes, given the system's technical structure, operational constraints, and business requirements. By completing the system accreditation process, the senior managers accept the risks associated with the system.

The role of certification in the SDLC is similar to the role of system quality assurance in that the certification process validates, verifies, and tests the system's features. Certification evaluates the system to determine whether the system operates according to the requirements and does not deliver new functionality introducing new risks. Certification includes total system performance and security policy compliance in security validation, security verification, security testing and evaluation, and system risk assessments. In addition to determining the system's compliance to security and policy requirements, the certification process must ensure the system complies with technical and regulatory requirements. It is important that applicable policies and safeguards are identified as early as possible in the SDLC.

Security officers, auditors, quality control employees, and management responsible for accreditation have security responsibilities. Security officials are closer to the day-to-day operation of the system and direct, perform, and monitor security tasks. The general system manager will have responsibility for the organization supported by the system. Accreditation is not a decision that should be made by the security office, rather it is the duty of the business manager to accept the system along with its associated risks. Formalization of the system accreditation process reduces the potential that systems will be placed into a production environment without appropriate management review.

Management acceptance of the system must be based on an assessment of management, operational, and technical controls. Because the security plan establishes the system protection requirements and documents the security controls in the system, it should form the basis for the system's accreditation. System accreditation is usually supported by a technical or security evaluation (or both), risk assessment, contingency plan, audit, and acknowledged policies of acceptable user behavior.

Reaccreditation should occur after any significant system change and at least every two to three years. If there is a high degree of risk, it should be performed more often. Following are the minimum security controls that must be in place prior to accrediting a system to begin processing. These principles should be made part of policies regarding systems development.

The level of controls should be consistent with the level of data or system sensitivity

- Technical and security evaluation complete

- Risk assessment conducted

- Policies of acceptable behavior established and acknowledged by users

- Disaster recovery and business resumption plans developed and tested

- System survivability and security plan developed, updated, and reviewed

- System meets all applicable laws, regulations, policies, and operations standards

- Safeguards operating as intended

- Auditing processes developed and implemented

Connecting to the Internet: Policies and Procedures of Survivability

Computer networks such as the Internet that do not have central administrative controls or unified security policies should be called open-ended networks. Because of their open-ended nature, there is no realistic way to determine just how many nodes are attached to the network. Regardless of the best efforts of information security officers, no degree of hardening will assure that a computer system that is connected to an open-ended system can be made invulnerable to attacks. However, if systems were designed with the goal of delivering profitable services while maintaining properties such as confidentiality, integrity, and availability, they would go a long way to contributing to an organization's survivability in the face of disasters.

Today's large-scale networks are highly distributed in an effort to improve efficiency and effectiveness by permitting high levels of integration. These levels of integration, while providing great strength of communication between networks, also carry elevated risks associated with unauthorized intrusion and compromise. These risks can be somewhat mitigated by implementing survivability in an organization's systems. Survivability incorporates risk management, fault tolerance, performance testing, and auditing.

Survivability is easily defined as the capability of a system attached to an open-ended network to continue to deliver profitable services in the presence of accidents, attacks, or systems failures.

The terms accidents, attacks, and failures are meant to include all potentially damaging events. Attacks include intrusions, viruses, worms, Trojan horses, and denial-of-service attacks. Any system with an overly restrictive structure because of attack threats may significantly reduce its functionality while directing excessive resources to protect and monitor its assets.

Failures and accidents are risks caused by deficiencies in the system itself, or in an external item on which the system depends. Failures may be attributable to design errors, human errors, hardware failures, coding errors, or corrupted data.

Accidents are usually described as random events such as naturally occurring disasters such as floods, blizzards, earthquakes, etc.

For a system to achieve high levels of survivability, it must react to and recover from damaging events while continuing to deliver efficient and effective services. In fact, reaction and recovery must be at acceptable levels whether or not the cause of the damaging event is ascertained. Levels of survivability are central to the notion that the system is sufficiently redundant that even if significant portions of the system were damaged or destroyed, the system would continue to meet demands.

For example, a survivable financial system maintains confidentiality, integrity, and availability of critical information when nodes or communication systems are not functioning as a result of harmful events. This financial system is survivable owing to its robust design. It recovers and delivers critical services in a timely manner in the face of disaster. The hallmark of a survivable system is the identification of critical services, the essential components that support them within the system and the ability to deliver these services in spite of harmful events. These are some of the key elements of survivable systems connected to open-ended networks:

Resistance to attacks. Strategies include strong user authentication and verification, configuration management, change controls, upgrade and patching policies, audit policies, antivirus policies, e-mail policies; partitioned sub-networks; firewalls; proxy services; network address translation services; redundant data backup copies and critical services; and well-developed risk-management programs.

Recognition of system attacks. Strategies include detecting intrusion attacks and understanding the current state of the system such that evaluating the extent of damage can be accomplished effectively.

Creation of event and transactions logs. These logs must document the external and internal activities taking place on the network. Having details contained in these logs can go a long way to saving your system administration and legal bacon. Many experienced administrators strongly suggest that logs are maintained on Write Once, Read Many (WORM) media. This logging media will prevent a malicious person from deleting his or her harmful activities once done.

Recognition of intrusion attack patterns. Strategies include virus scans, systems vulnerability scans, internal integrity checking, logging, audits, system monitoring, and network monitoring.

Recovery of full or critical services is based on critical asset prioritization, recovery, and business resumption.

Development and implementation of strategies for restoring the following: compromised data, critical functionality, limiting extent of damage, maintenance or resumption of critical services, and the eventual restoration of services as time and resources allow.

Restoration of critical data and applications. Use of alternative services, use of redundant components with same or similar interface, operational procedures to restore system configuration state, containment and isolation of damage, and practiced ability to operate critical services with reduced resources.

Risk management planning requires that risk management decisions and financial balances must be made by senior managers with guidance and recommendations of technical experts in application and data domains, security, and software engineering. System survivability depends at least as much on risk management development and implementation as it does on the technical abilities of the organization's employees. Experts in security and technical issues have the role of providing senior managers with the information necessary to make informed risk management decisions.

In the design of new systems or refitting older systems, survivability imposes structures on all phases of system and software development processes. At the requirement and specification levels, critical assets must be identified. Requirements for damage resistance, recognition, recovery, and resumption should be specifically addressed. System architectures should address survivability equally with other performance properties as capacity, reliability, and maintainability. In the selection of commercial off-the-shelf software, solutions should be chosen with survivability as one of the highest priorities.

Software solution design and implementation should include techniques for containment and isolation, replication, restoration, and migration of critical assets. Survivability solutions must be integrated into both new and existing systems, avoiding systems failure due to attack, accident, or natural disasters.