Trustworthiness: Validity and Reliability

Get Complete Project Material File(s) Now! »

Timetable

A comprehensive security plan cannot be executed instantly. The security plan includes a timetable that shows how and when the elements of the plan will be performed. These dates also give milestones so that management can track the progress of implementation. If the implementation is to be a phased development (that is, the system will be implemented partially at first, and then changed functionally or performance will be added in later stages), the plan should also describe how the security requirements will be implemented over time. Even when overall development is not phased, it may be desirable to implement the security aspects of the system over time. For example, if the controls are expensive or complicated, they may be acquired and implemented gradually. Similarly, procedural controls may require staff training to ensure that everyone understands and accepts the reason for the control.
The plan should specify the order in which the controls are to be implemented so that the most serious exposures are covered as soon as possible. A timetable also gives milestones by which to judge the progress of the security program.
Furthermore, the plan must be extensible. Conditions will change: new equipment will be acquired, new degrees and modes of connectivity will be requested, and new threats will be identified. The plan must include a procedure for change and growth, so that the security aspects of changes are considered as part of preparing for the change, not for adding security after the change has been made. The plan should also contain a schedule for periodic review. Even though there may have been no obvious, major growth, most organizations experience modest change on a daily basis. At some point the cumulative impact of the change is enough to require the plan to be modified.

Continuing Attention

Good intentions are not enough when it comes to security. Institutions and corporate bodies must not only take care in defining requirements and controls, but they must also find ways for evaluating a system’s security to be sure that the system is as secure as they intend it to be. Thus, the security plan must call for reviewing the security situation periodically. As users, data, and equipment change, new exposures may develop. In addition, the current means of control may become obsolete or ineffective (such as when faster processor times enable attackers to break an encryption algorithm). The inventory of objects and the list of controls should periodically be scrutinized and updated, and risk analysis performed anew.
The security plan should set times for these periodic reviews, based either on calendar time (such as, review the plan every nine months) or on the nature of system changes (such as, review the plan after every major system release).

Business Continuity Plans

Small companies working on a low profit margin can literally be put out of business by a computer incident. Large, financially sound businesses can weather a modest incident that interrupts their use of computers for a while, although it is painful to them since they do not want to spend money unnecessarily. The analysis is sometimes as simple as no computers means no customers mean no sales means no profit. (Pfleeger et al, 2003).
Government agencies, educational institutions, and nonprofit organizations also have limited budgets, which they want to use to further their needs. They may not have a direct profit motive, but being able to meet the needs of their customers—the public, students, and constituents—partially determine how well they will fare in the future. All kinds of organizations must plan for ways to cope with emergency situations. A business continuity plan documents how a business will continue to function during a computer security incident.
An ordinary security plan covers computer security during normal times and deals with protecting against a wide range of vulnerabilities from the usual sources. A business continuity plan deals with situations having two characteristics:
• Catastrophic situations, in which all or a major part of a computing capability is suddenly unavailable
• Long duration, in which the outage is expected to last for so long that business will suffer

READ A comprehensive framework to test Network Awareness

There are many situations in which a business continuity plan would be helpful. Here are some examples that typify what one might find in reading articles and newspapers:
• A fire destroys a company’s entire network
• A seemingly permanent failure of a critical software component renders the computing system unusable.
• A business must deal with the abrupt failure of its supplier of electricity, telecommunications, network access, or other critical service.
• A flood prevents the essential network support staff from getting to the operations center.

As one can see, these examples are likely to recur, and each disables a vital function. The key to coping with such disasters is advanced planning and preparation, identifying activities that will keep a business viable when the computing technology is disabled. According to Pfleeger et al, the steps in business continuity planning are these:
• Assess the business impact of a crisis.
• Develop a strategy to control impact.
• Develop and implement a plan for the strategy.

Incidence Response Plans

An incidence response plan tells the staff how to deal with a security incidence. In contrast to the business continuity plan, the goal of incident response is handling the current security incident, without regard for the business issues. The security incident may at the same time be a business catastrophe, as addressed by the business continuity plan. But as a specific security event, it might be less than catastrophic (that is, it may not interrupt business severely) but could be a serious breach of security, such as a hacker attack or a case of internal fraud. An incident could be a single event, a series of events, or an ongoing problem

1 Introduction
1.1 Background of the Study .
1.2 Problem of the Study
1.4 Research Questions
1.6 Disposition.
2 Theorethical Framework
2.1 Security Planning and Plan
2.2 Risk Analysis
2.3 Organizational Security Policies
2.4 Physical Security
3 METHODOLOGY
3.1 Choice of method
3.2 Method of analysis.
3.3 Data collection
3.4 Choice of respondents.
3.5 Trustworthiness: Validity and Reliability
4 EMPIRICAL FINDINGS.
4.1 Saab Training Systems
4.2 Jönköping University .
4.3 Kitron Development AB
4.4 Elite Stora Hotellet, Jonkopin
4.5 Scandic Hotel
5 ANALYSIS.
5.1 Security Plan
5.2 Risk Analysis
5.3 Security Policy
5.4 Disasters and Physical Threats
6 CONCLUSION