Case Study and Discussion
Creating and
maintaining
effective security
strategy and policy
for software
applications.
A Policy Framework for Information Security
A s organizations increasingly rely on information systems as the pri- mary way to conduct operations, keeping such systems (and the asso- ciated data) secure receives increasing emphasis. However, the prevalent model within many organizations appears to be an ad hoc
approach to security, where the latest hreach becomes the model for fliture occurrences. For example, Microsoft issued over 80 critical patches for its IIS Web Server software over the past three years. Despite the low initial cost of the software, the maintenance costs over time are prohibitive [2]. A well-designed and maintained security policy potentially can reduce such costly forays, as well as provide protection from disaster.
Our objective here is to provide information security professionals and top management a tramework through which useable security strategy and policy for applications can be cre- ated and maintained in line with the standard information technology hfe cycle. This frame- work, the Policy Framework for Interpreting Risk in E-Business Security (PFIRES), was ini- tially developed for e-commerce activities and has since been generalized to handle securit)- policy for all types of organizations engaged in computing and Internet operations. This framework offers a possible starting point for
understanding a security policy's impact on an organization, and is intended to guide organi- zations in developing, implementing, and maintaining security policy.
Information Security Policy Security policies are generally high-level, tech- nology neutral, concern risks, set directions and procedures, and define penalties and countermeasures if the policy is transgressed, and must not be confused with implementa- tion-specific information, which would be part of the security standards, procedures, and
BY JACKIE REES, SUBHAIYOTI BANDYOPADHYAY, AND EUGENE H . SPAFFORD
COMMUNICATIONSOFTHEACM July 200J/Vol. 46, No 7 101
guidelines. Security policies are created by empow- ered organizational representatives from human resources, legal and regulatory matters, information systems, public relations, security, and the various lines of business. A guideline for developing Inter- net-specific security policy was discussed in [5], while more generalizable security policies and guidelines can be found in [8]. The problem with current approaches is that none address the prob- lem of keeping up with the increasing rate of change in technology and applications nor do they consider how to keep such policies consistent and aligned with organiza- tional objectives.
To develop a tool to aid in the formulation and management of security policies, other tools in similarly changing busi- ness arenas were exam- ined. As is the case for most systems problems, the best approach was found to be a structured one, including analyzing risk and delegating resources to protect the most valued assets of the organization [1]. PFIRES was developed borrowing from both the new prod- uct development life cycle [7], and the systems development life cycle (SDLC) [4].
While creating security policy is not an exact sci- ence, well-defined processes can be put into place so that all security-related requirements are systemati- cally considered. An analogue is the SDLC, which embodies a well-defined process for considering busi- ness requirements, translating such requirements into an information systems context, and then devel- oping an information system that supports those requirements. PFIRES is intended to be systematic, yet dynamic. The framework is detailed enough to ensure that an organization does not overlook any- thing while addressing a security issue, but dynamic enough to ensure the speed and execution required to adapt rapidly to changing business scenarios.
A Policy Framework for Interpreting Risk in E-Business Security The PFIRES life cycle consists of four major phases: Assess, Plan, Deliver, and Operate, as shown in Fig-
Feedback
Figure i . PFIRES life-cycle model.
ure 1. Because policy development is an iterative process, the model includes feedback loops at every step. Feedback is also necessary to ensure the requirements of the previous step are satisfied.
Organizational change is defined as a continuum, with the two end points being tactical and strategic. Tactical changes involve short-term goal achieve- ment and how to control and evaluate the process of achieving goals, whereas strategic changes are long- term, broad-based initiatives involving positioning
within the marketplace and typically involve members ot senior man- agement [6]. Most orga- nizational change falls somewhere between these two end points.
Assess Phase The Assess phase can be initiated by two dis- tinct events: either a decision to execute the model from scratch or .1 response to a pro- posed change output from the Review Trends and Manage Events step. In either case, the goal is to assess
the proposed change against the existing policy and organizational environment. The Assess phase has three possible results, as shown in Figure 2.
For a company executing the PFIRES model for the first time, the Assess phase is the logical starting point. However, before beginning the process of implementing security policy, the company needs to review existing policy and complete a full risk assess- ment. These are conducted during the two steps included in the Assess phase: Policy Assessment and Risk Assessment.
Policy Assessment. Whether PFIRES is initiated as a result of initial policy creation or a change to existing policy. Policy Assessment is conducted to review existing policies, standards, guidelines, and procedures. The determination of whether the pro- posed change is strategic or tactical will affect how steps later in the life cycle will be explored; however, if this is the organizations first time executing the model, the effort is by definition strategic in nature.
There are four sub-steps within the Policy Assess- ment step: Analyze Policy Environment, Identify Policy Gaps and Contradictions, Summarize Policy Assessment Results, and Develop Policy Recom-
Environment
102 July 2003/Vol 46, No. 7 COMMUNICATIONS OF THE ACM
mendations. Executed in sequence, these sub-steps result in a decision regarding vt^hether to accept the proposed changes and an assessment of how the pro- posed change afFects existing policy.
Once the policy assessment is complete, a deci- sion needs to be made on where the proposed change falls within the change continuum. The posi- tion on the change continuum that the proposed change falls in will help determine the scope of the Risk Assessment step, thus influencing the execution of the subsequent steps of the life cycle.
Risk Assessment. Risk Assessment identifies the business assets an organiza- tion wants to protect, and identifies potential threats to Figure 2. The Assess phase those assets. The various flowchart sub-steps in the risk assessment process are:
• Conduct Security Assessment identifies elements in the current or proposed environment subject to threats that could compromise information assets.
• Assess Business Risk identifies the most valuable assets in terms of security. While intangible assets are difficult to valuate, it is beneficial to rank them.
• Develop Security Recommendations involves identifying security options, determining payroll and non-payroll cost, determining the priority of options, verifying results and developing a cost/benefit matrix.
• Summarize Assessment Final Recommendations documents the results of both the Policy and Risk Assessments so management can decide whether to accept the proposed change. If accepted, the life cycle for this particular proposed change con- tinues in the Plan phase. If rejected, but it is determined that other policy changes are required, the Plan phase follows as well. Other- wise, the life cycle resumes in the Operate phase.
Plan Phase The Plan phase prepares for the implementation of the proposed change including creating or updating
Resume Operate Phase
No, but policy needs updating
policy and defining the requirements for the pro- posed change. The Plan Phase has two sub-steps. Policy Development and Requirements Definition.
Policy Development. It is vital to develop security strategy and policy that is in line with existing busi- ness strategy and policy. Activities during Policy Development assure this. Policy Development itself consists of two suh-steps: Create/Update Security
Strategy and Cre- ate/Update Security Policy.
Create/Update Security Strategy, Security strategy is an overview of future business direction along with the secu- rity controls needed
to support these business functions. A security strat- egy session should be held consisting of the follow- ing tasks: identify fijture business initiatives; identify risks to each initiative; identify security options; pri- oritize security initiatives and document security strategy. This session should include key manage- ment personnel not only for their thought leadership but to gain their confidence in the entire process.
Create/Update Security Policy. Specific tasks of this sub-step include identifying areas for security policy, drafting security policy, reviewing security policy and publishing security policy.
Require?nents Definition. Within Requirements Definition an organization analyzes its security pol- icy in order to define the requirements of the new security architecture in light of the updated policy. The three sub-steps are outlined here.
Translate Recommendations to Requirements. The high-priority recommendations developed in the Risk Assessment are used in this sub-step to create the security infrastructure necessary to support the change.
Develop Detailed Security Requirements. The high- level requirements from the previous sub-step are expanded to a sufficient level of detail so that control selection can begin. This sub-step carefully considers the overall technical environment so that the pro- posed change will tightly integrate and support the
Because policy development is an iterative process, the
model includes feedback loops at every step.
COMMUNICATIONS OF THE ACM July 1003/Vol 46. No 7 103
existing environment. Interoperability requirements such as systems and network support, and standards and application programming interface support must be considered.
Verify Requirements. The requirements defined in the previous two sub-steps are validated against the inputs to the Requirements Definition step. All requirements should map back to a specific risk (as doc- umented in the Risk Assess- ment) or to a specific point in the Security Policy. It is also important during this sub- step to evaluate the detailed requirements against industry best practices. Additionally, particular market segments may need to meet requirements specified by their country or local gov- ernment, or by other authoritative bodies.
The Deliver Phase The Deliver Phase is the actual implementation of the policy. The phase consists of two steps: Controls definition and Controls implementation, as shown in Table 1.
Controls Definition. Controls are practices, pro- cedures or mechanisms that reduce security risks, and this step defines those needed to meet the requirements of the security policy. Controls Defin- ition consists of four sub-steps: Design Infrastruc- ture, Determine Controls, Evaluate Solutions, and Select Controls. These sub-steps are sequential in nature and follow the widely used SDLC [4].
Design Infrastructure. In this sub-step, the requirements from the Plan phase are used to design a high-level security infrastructure containing technical, procedural, and organizational components.
Determine Controls. The high-level designs are translated into controls and their requirements. Specific organizations may have additional requirements, such as a control pro- vided by a partner-vendor or other preferred provider.
Evaluate Solutions. The security marketplace is growing rapidly, and it is likely there will be several choices meeting the general requirements. The pur- pose of this sub-step is to identify and evaluate the options for each control and select the best option.
Select Controls. The solution best meeting the
figure 3- Activities in the Monitor Operations step.
Assess Plan
Deliver
Operate
^ ^ ^ ^ Sub-step ^ 1 ^ 1
Controls Definition
Controls Implementation
Design Infrastructure Determine Controls Evaluate Solucions Select Controls
Create Implementation Plan Build Test Pilot and Deployment
control requirements is selected and mapped to the infrastructure design. The controls list should be validated to assure duplicate requirements are not being met by different solutions and to identify opportunities for controls reuse across the security infrastructure.
Controls Implementation. This step implements the controls selected in the prior step. Activities include building, testing, and imple- menting the final security infrastructure. This step is executed through four sub- steps: Create Implementa- tion Plan, Build, Test, and Pilot and Deployment. During deployment, once the mfrastructute is in place in the "live" environment, a
final risk assessment should be performed to assure that all known threats have been addressed and the solution is secure.
Create Implementation Plan. A specific plan is cre- ated in order to translate design into reality. With a detailed plan, the security infrastructure is more likely to be built on time and to meet requirements.
Build. The scope of this sub-step will vary widely depending on the controls. However, there are some specific planning considerations. It is in this sub- step where detailed procedures and performance support are developed to support the selected con- trols. These procedures are critical to the successful
ongoing management and moni- toring of the security architec- ture. This sub-step also includes activities to develop training products including help files and manuals.
Test. Once the security infra- structure has been built, it must be tested to ensure the design was completely executed, the identi- fied threats have been addressed, and no new vulnerabilities have been identified. Activities during this sub-step will include three
types of testing: vulnerability assessment, security infrastructure validation, and appliaition security support.
Pilot and Deployment. Once tested, the security infrastructure is deployed to the production envi- ronment. Whether a pilot is required depends on scope. Deployment includes configuring and installing security architecture components and
Table 1. The Deliver phase steps and sub-steps.
104 July 200J/Vol.46,No. 7 COMMUNICATIONS OF THE ACM
With a detailed plan, the security infrastructure is more
likely to he huilt on time and to meet requirements.
rolling out new processes and procedures through communication and training. Deployment should ensure that security requirements as set forth in the policy are met, and that no new security risks are introduced.
Operate Phase The Operate phase occurs on a daily basis. Its pur- pose is to monitor the controls that have been put in place to secure the organization and handle incidents as they arise. In addition, business and technology trends are watched and analyzed.
Monitor Operations. The purpose of this step is to define the daily activities throughout the organi- zation to ensure the security policy is enforced across the security infrastructure. These activities can be broken into a few general categories as depicted in Figure 3. This step is unique because it is not clearly executed through a series ot sub-steps, but instead consists of several simultaneous activities that must coexist to support the environment.
Administration and Operations. This activity covers administrative functions and can include, but is not lim- ited to: user administra- tion {adding, deleting, and modifying system and application users); evaluating and applying security patches to systems and applications; system and application monitoting for security events; monitoring security news resources for new vulnerabilities and administering anti-virus applications
Communications. This activity communicates to different audiences the appropriate security messages (see Table 2). Each organization will have several dif- ferent audiences, some requiring only an awareness of security, and others requiring time-sensitive infor- mation.
Investigations. Investigations includes activities necessary to examine a situation or incident, deter- mine root cause or verify facts, and recommend action. Common situations where ati investigation
End Users
Unix Security Administrators
• Protect your authentlcaton credentials • Do not download material from
unknown sources • Comply with Internee acceptable use
policies
• Review recenc CERT alerts on new vulnerabilities
• Change security standards based on new threats
• Installation procedures for tested security patches to install
will be necessary include: after a break-in or hack has occurred; when an employee is suspected of violating corporate policy; after an unplanned security event caused a system to crash and afi:er a fraud has occurred.
Security Services. Security services deals with pro- viding security specialists to project teams as they design new capabilities, refine existing processes, or otherwise undertake change within the environ- ment. The security services function can be viewed as a consulting role and can be filled by a dedicated group within the security organization or by an external service provider.
Compliance. Compliance includes those activities necessary to ensure the infrastructure is following security policy guidelines. It is typically thought of as an internal audit function, but a security compliance program is more proactive than quarterly audit reports and findings.
Review Trends and Manage Events. A security pol- icy that is not constantly evaluated and updated is of no value. This final activity identifies those events or trends that may signal a need to reevaluate the security policy. This step can be broken down into the following four sub-steps: Manage events {planned and unplanned); Identify internal trends; Identify external trends; and Escalate to Assess phase. As in the Monitor Operations step, these activities are not sequential. Although escalation is always the last step, event man- agement and trend identification
can take place simultaneously.
Manage Events. Events are situations outside of normal activity, for example, individuals violating an acceptable use policy by seeking sports scores on the Web during business hours. Although outside of approved or normal activity, such an event can easily be planned for by establishing procedures so if it does occur it can be processed as part of planned operations. Conversely, there are situations that can be anticipated but not in exact detail, such as data destruction. These unexpected events require an
Table 2. Examples of communications messages.
COMMUNICATIONS OF THE ACM July 2003/Vol 46, No 7 105
By effectively managing security risks, the organization is
better positioned to successfully achieve its objectives.
incident response process including documenting the incident, maintaining records of what was altered during the incident, providing appropriate information to support legal action, procedures for tracing the source of an event, guidelines for when or how to escalate an event through chain of man- agement, and procedures for containment of events to limit damage [3].
Identify External Trends. This sub-step looks for external trends that may indicate the need to reassess current security policy. Its key components are iden- tifying information that may have security relevance and determining whether to escalate a trend or event to the Assess phase. To determine if an event or trend should be escalated, it must be considered within the context of the organization's industry, and should be evaluated in terms of organizational priorities.
Identify Internal Trends. Internal trends can come from new business opportunities, new capabilities, or new applications. They might also arise from an existing business or security process.
Escalate to Assess Phase. N o t all changes should be escalated to the Assess phase—common sense and a set of criteria should prevail. These criteria need not be pages of detailed considerations, but they should validate a true impetus for change. Three key issues should be examined: scope of impact (will this change impact a single business unit ot will it have a global business impact?), timeliness (has the need for this change been proven over time?) and momentum (is there support among key stakeholders—system administrators, application owners, business unit leaderŝ —-that this change is necessary?).
The Future As a high-level policy management tool, PFIRES facilitates communication between senior manage- ment and technical security management. With improved communication, the organization should realize immediate benefits—increased protection from and responsiveness to security incidents related to computing activities, including e-business opera- tions. By effectively managing security risks, the organization is better positioned to successfully achieve its objectives.
Much work remains to be done in this area. Inter-
national and regional concerns, organizational behavior, legal issues, supply chain factors, and industty-specific concerns are a few areas that would benefit from an in-depth exploration of related information security policy. Enhanced models and tools for analyzing and managing information secu- rity infrastructure investments are also needed. Cer- tainly, tesearch needs to be conducted into how well the life cycle meets the policy management needs of today's organizations and what improvements need to be made to ensure future success. Q
REFERENCES 1. Baskcrville. R. Information systems security design methods: Implica-
tions for information systems development. ACM Computing Surveys 25, 4 (Apr. 1993}.
2. Gartner, Inc. Nimda Worm Shows You Can't Always Patch Fast Enough. Note FT-14-5524 (2001); www.gartner.com
3. Guttman, B. and Robach, E.A. An Introduction co Computer Security: The N/S7' Handbook. National Institute of Standards and Technology, 1995.
4. HofFcr, J.A., Geoi^e, J.F., and Valacich, J.S. Modem Systems Analysis and Design. Addison-Wesley, Reading, MA, 1999.
5. Lichrenstein, S. Developing Internet security policy for organizations. In Proceeding of the Thirtieth Hawaii International Conference on Systems Sciences. J.F, Nunamaker, jr. and R.H. Sprague, Jr., ti^s. IEEE Com- puter Society, 1997.
6. Porter, M.E. Competitive Strategy: Technitjues far Analyzing Industries and Competitors. The Free Press, New York, 1980.
7. Vernon, R. Internaiional investment and international trade in the prod- uct cycle. Quarterly Journal of Economics 80.
8. Wood, C.C Writing IntoSec policies. Compute}-! and Security 7^(1995).
J A C K I E R E E S (jrees@mgmt.purdue.edu) is an assistant professor of management at the Krannert Graduate School of Management at Purdue University. Iiidian.i. SUBHAJYOTI B A N D Y O P A D H A Y (bandyos@notes.cba-ufl.cdu) is an assistant professor of Decision and ]nform;icion Sciences at the Warrington College of Business Administration at the University of Florida. E U G E N E H , S P A F F O R D (spaf@cerias.purdue.edu) is a professor of
Computer Science at Purdue University and the director of the Center for Educadon and Research in Information Assurance and Security (CERIAS).
This research was supporteti by the Center for Ediitation and Research in Informa- tion Assurance and Security (CERIAS) and Acctnrure.
Permission to make digital or hard copies of all or part of this work for personal or class- room use IS j,'ranced without fee provided that copies arc not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. Tti iiipy otherwise, to republish, to post on servers or to recJJscribute to lists, requires prior specific permission and/or a fee.
© 2 0 0 3 ACM 0 0 0 2 - 0 7 8 2 / 0 3 / 0 7 0 0 15.00
rO6 July 2003/Vol 46, No 7 COMMUNtCATIONS OFTHE ACM