Creating and

maintaining

effective security

strategy and policy

for software

applications.

A Policy Framework forInformation Security

As 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, theprevalent model within many organizations appears to be an ad hoc

approach to security, where the latest hreach becomes the model for flitureoccurrences. For example, Microsoft issued over 80 critical patches for its IISWeb Server software over the past three years. Despite the low initial cost of thesoftware, the maintenance costs over time are prohibitive [2]. A well-designedand maintained security policy potentially can reduce such costly forays, as wellas provide protection from disaster.

Our objective here is to provide informationsecurity professionals and top management atramework through which useable securitystrategy and policy for applications can be cre-ated and maintained in line with the standardinformation technology hfe cycle. This frame-work, the Policy Framework for InterpretingRisk in E-Business Security (PFIRES), was ini-tially developed for e-commerce activities andhas since been generalized to handle securit)-policy for all types of organizations engaged incomputing and Internet operations. Thisframework offers a possible starting point for

understanding a security policy's impact on anorganization, and is intended to guide organi-zations in developing, implementing, andmaintaining security policy.

Information Security PolicySecurity policies are generally high-level, tech-nology neutral, concern risks, set directionsand procedures, and define penalties andcountermeasures if the policy is transgressed,and must not be confused with implementa-tion-specific information, which would be partof 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 humanresources, legal and regulatory matters, informationsystems, public relations, security, and the variouslines of business. A guideline for developing Inter-net-specific security policy was discussed in [5],while more generalizable security policies andguidelines can be found in [8]. The problem withcurrent approaches is that none address the prob-lem of keeping up with the increasing rate ofchange in technology andapplications nor do theyconsider how to keep suchpolicies consistent andaligned with organiza-tional objectives.

To develop a tool to aidin the formulation andmanagement of securitypolicies, other tools insimilarly changing busi-ness arenas were exam-ined. As is the case formost systems problems,the best approach wasfound to be a structuredone, including analyzingrisk and delegatingresources to protect themost valued assets of theorganization [1]. PFIRESwas developed borrowingfrom both the new prod-uct development life cycle [7], and the systemsdevelopment life cycle (SDLC) [4].

While creating security policy is not an exact sci-ence, well-defined processes can be put into place sothat all security-related requirements are systemati-cally considered. An analogue is the SDLC, whichembodies a well-defined process for considering busi-ness requirements, translating such requirementsinto an information systems context, and then devel-oping an information system that supports thoserequirements. PFIRES is intended to be systematic,yet dynamic. The framework is detailed enough toensure that an organization does not overlook any-thing while addressing a security issue, but dynamicenough to ensure the speed and execution requiredto adapt rapidly to changing business scenarios.

A Policy Framework for InterpretingRisk in E-Business SecurityThe PFIRES life cycle consists of four major phases:Assess, Plan, Deliver, and Operate, as shown in Fig-

Feedback

Figure i . PFIRES life-cyclemodel.

ure 1. Because policy development is an iterativeprocess, the model includes feedback loops at everystep. Feedback is also necessary to ensure therequirements 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 ofachieving goals, whereas strategic changes are long-term, broad-based initiatives involving positioning

within the marketplaceand typically involvemembers ot senior man-agement [6]. Most orga-nizational change fallssomewhere betweenthese two end points.

Assess PhaseThe Assess phase canbe initiated by two dis-tinct events: either adecision to execute themodel from scratch or.1 response to a pro-posed change outputfrom the ReviewTrends and ManageEvents step. In eithercase, the goal is to assess

the proposed change against the existing policy andorganizational environment. The Assess phase hasthree possible results, as shown in Figure 2.

For a company executing the PFIRES model forthe first time, the Assess phase is the logical startingpoint. However, before beginning the process ofimplementing security policy, the company needs toreview existing policy and complete a full risk assess-ment. These are conducted during the two stepsincluded in the Assess phase: Policy Assessment andRisk Assessment.

Policy Assessment. Whether PFIRES is initiatedas a result of initial policy creation or a change toexisting policy. Policy Assessment is conducted toreview existing policies, standards, guidelines, andprocedures. The determination of whether the pro-posed change is strategic or tactical will affect howsteps later in the life cycle will be explored; however,if this is the organizations first time executing themodel, the effort is by definition strategic in nature.

There are four sub-steps within the Policy Assess-ment step: Analyze Policy Environment, IdentifyPolicy Gaps and Contradictions, Summarize PolicyAssessment Results, and Develop Policy Recom-

Environment

102 July 2003/Vol 46, No. 7 COMMUNICATIONS OF THE ACM

mendations. Executed in sequence, these sub-stepsresult in a decision regarding vt^hether to accept theproposed 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 proposedchange falls within the change continuum. The posi-tion on the change continuum that the proposedchange falls in will helpdetermine the scope of theRisk Assessment step, thusinfluencing the execution ofthe subsequent steps of thelife cycle.

Risk Assessment. RiskAssessment identifies thebusiness assets an organiza-tion wants to protect, andidentifies potential threats to Figure 2. The Assess phasethose assets. The various flowchartsub-steps in the risk assessment process are:

• Conduct Security Assessment identifies elementsin the current or proposed environment subject tothreats that could compromise information assets.

• Assess Business Risk identifies the most valuableassets in terms of security. While intangible assetsare difficult to valuate, it is beneficial to rank them.

• Develop Security Recommendations involvesidentifying security options, determining payrolland non-payroll cost, determining the priority ofoptions, verifying results and developing acost/benefit matrix.

• Summarize Assessment Final Recommendationsdocuments the results of both the Policy and RiskAssessments so management can decide whetherto accept the proposed change. If accepted, thelife cycle for this particular proposed change con-tinues in the Plan phase. If rejected, but it isdetermined that other policy changes arerequired, the Plan phase follows as well. Other-wise, the life cycle resumes in the Operate phase.

Plan PhaseThe Plan phase prepares for the implementation ofthe proposed change including creating or updating

ResumeOperatePhase

No, but policy needsupdating

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 securitystrategy and policy that is in line with existing busi-ness strategy and policy. Activities during PolicyDevelopment assure this. Policy Development itselfconsists of two suh-steps: Create/Update Security

Strategy and Cre-ate/Update SecurityPolicy.

Create/UpdateSecurity Strategy,Security strategy is anoverview of futurebusiness directionalong 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; identifyrisks to each initiative; identify security options; pri-oritize security initiatives and document securitystrategy. This session should include key manage-ment personnel not only for their thought leadershipbut to gain their confidence in the entire process.

Create/Update Security Policy. Specific tasks of thissub-step include identifying areas for security policy,drafting security policy, reviewing security policyand publishing security policy.

Require?nents Definition. Within RequirementsDefinition an organization analyzes its security pol-icy in order to define the requirements of the newsecurity architecture in light of the updated policy.The three sub-steps are outlined here.

Translate Recommendations to Requirements. Thehigh-priority recommendations developed in theRisk Assessment are used in this sub-step to createthe security infrastructure necessary to support thechange.

Develop Detailed Security Requirements. The high-level requirements from the previous sub-step areexpanded to a sufficient level of detail so that controlselection can begin. This sub-step carefully considersthe 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 requirementssuch as systems and network support, and standardsand application programming interface supportmust be considered.

Verify Requirements. The requirements defined inthe previous two sub-steps are validated against theinputs to the Requirements Definition step. Allrequirements should mapback to a specific risk (as doc-umented in the Risk Assess-ment) or to a specific point inthe Security Policy. It is alsoimportant during this sub-step to evaluate the detailedrequirements against industrybest practices. Additionally,particular market segments may need to meetrequirements specified by their country or local gov-ernment, or by other authoritative bodies.

The Deliver PhaseThe Deliver Phase is the actual implementation ofthe policy. The phase consists of two steps: Controlsdefinition and Controls implementation, as shownin Table 1.

Controls Definition. Controls are practices, pro-cedures or mechanisms that reduce security risks,and this step defines those needed to meet therequirements of the security policy. Controls Defin-ition consists of four sub-steps: Design Infrastruc-ture, Determine Controls, Evaluate Solutions, andSelect Controls. These sub-steps are sequential innature and follow thewidely used SDLC [4].

Design Infrastructure.In this sub-step, therequirements from thePlan phase are used todesign a high-level securityinfrastructure containingtechnical, procedural, andorganizational components.

Determine Controls.The high-level designs are translated into controlsand their requirements. Specific organizations mayhave additional requirements, such as a control pro-vided by a partner-vendor or other preferredprovider.

Evaluate Solutions. The security marketplace isgrowing rapidly, and it is likely there will be severalchoices meeting the general requirements. The pur-pose of this sub-step is to identify and evaluate theoptions for each control and select the best option.

Select Controls. The solution best meeting the

figure 3- Activities in theMonitor Operations step.

AssessPlan

Deliver

Operate

^ ^ ^ ^ Sub-step ^ 1 ^ 1

ControlsDefinition

ControlsImplementation

Design InfrastructureDetermine ControlsEvaluate SolucionsSelect Controls

Create Implementation PlanBuildTestPilot and Deployment

control requirements is selected and mapped to theinfrastructure design. The controls list should bevalidated to assure duplicate requirements are notbeing met by different solutions and to identifyopportunities for controls reuse across the securityinfrastructure.

Controls Implementation. This step implementsthe controls selected in theprior step. Activities includebuilding, testing, and imple-menting the final securityinfrastructure. This step isexecuted through four sub-steps: Create Implementa-tion Plan, Build, Test, andPilot and Deployment.During deployment, oncethe mfrastructute is in placein the "live" environment, a

final risk assessment should be performed to assurethat all known threats have been addressed and thesolution is secure.

Create Implementation Plan. A specific plan is cre-ated in order to translate design into reality. With adetailed plan, the security infrastructure is morelikely to be built on time and to meet requirements.

Build. The scope of this sub-step will vary widelydepending on the controls. However, there are somespecific planning considerations. It is in this sub-step where detailed procedures and performancesupport 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 includesactivities to develop trainingproducts including help files andmanuals.

Test. Once the security infra-structure has been built, it mustbe tested to ensure the design wascompletely executed, the identi-fied threats have been addressed,and no new vulnerabilities havebeen identified. Activities duringthis sub-step will include three

types of testing: vulnerability assessment, securityinfrastructure validation, and appliaition securitysupport.

Pilot and Deployment. Once tested, the securityinfrastructure is deployed to the production envi-ronment. Whether a pilot is required depends onscope. Deployment includes configuring andinstalling security architecture components and

Table 1. The Deliverphase steps andsub-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 throughcommunication and training. Deployment shouldensure that security requirements as set forth in thepolicy are met, and that no new security risks areintroduced.

Operate PhaseThe Operate phase occurs on a daily basis. Its pur-pose is to monitor the controls that have been put inplace to secure the organization and handle incidentsas they arise. In addition, business and technologytrends are watched and analyzed.

Monitor Operations. The purpose of this step isto define the daily activities throughout the organi-zation to ensure the security policy is enforced acrossthe security infrastructure. These activities can bebroken into a few general categories as depicted inFigure 3. This step is unique because it is not clearlyexecuted through a series ot sub-steps, but insteadconsists of several simultaneous activities that mustcoexist to support theenvironment.

Administration andOperations. This activitycovers administrativefunctions and caninclude, but is not lim-ited to: user administra-tion {adding, deleting,and modifying systemand application users);evaluating and applying security patches to systemsand applications; system and application monitotingfor security events; monitoring security newsresources for new vulnerabilities and administeringanti-virus applications

Communications. This activity communicates todifferent audiences the appropriate security messages(see Table 2). Each organization will have several dif-ferent audiences, some requiring only an awarenessof security, and others requiring time-sensitive infor-mation.

Investigations. Investigations includes activitiesnecessary to examine a situation or incident, deter-mine root cause or verify facts, and recommendaction. Common situations where ati investigation

End Users

Unix SecurityAdministrators

• Protect your authentlcaton credentials• Do not download material from

unknown sources• Comply with Internee acceptable use

policies

• Review recenc CERT alerts on newvulnerabilities

• Change security standards based onnew threats

• Installation procedures for testedsecurity patches to install

will be necessary include: after a break-in or hack hasoccurred; when an employee is suspected of violatingcorporate policy; after an unplanned security eventcaused a system to crash and afi:er a fraud hasoccurred.

Security Services. Security services deals with pro-viding security specialists to project teams as theydesign new capabilities, refine existing processes, orotherwise undertake change within the environ-ment. The security services function can be viewedas a consulting role and can be filled by a dedicatedgroup within the security organization or by anexternal service provider.

Compliance. Compliance includes those activitiesnecessary to ensure the infrastructure is followingsecurity policy guidelines. It is typically thought of asan internal audit function, but a security complianceprogram is more proactive than quarterly auditreports and findings.

Review Trends and Manage Events. A security pol-icy that is not constantly evaluatedand updated is of no value. Thisfinal activity identifies those eventsor trends that may signal a need toreevaluate the security policy. Thisstep can be broken down into thefollowing four sub-steps: Manageevents {planned and unplanned);Identify internal trends; Identifyexternal trends; and Escalate toAssess phase. As in the MonitorOperations step, these activities arenot sequential. Although escalationis always the last step, event man-agement and trend identification

can take place simultaneously.

Manage Events. Events are situations outside ofnormal activity, for example, individuals violating anacceptable use policy by seeking sports scores on theWeb during business hours. Although outside ofapproved or normal activity, such an event can easilybe planned for by establishing procedures so if itdoes occur it can be processed as part of plannedoperations. Conversely, there are situations that canbe anticipated but not in exact detail, such as datadestruction. These unexpected events require an

Table 2. Examplesof communicationsmessages.

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 documentingthe incident, maintaining records of what wasaltered during the incident, providing appropriateinformation to support legal action, procedures fortracing the source of an event, guidelines for whenor how to escalate an event through chain of man-agement, and procedures for containment of eventsto limit damage [3].

Identify External Trends. This sub-step looks forexternal trends that may indicate the need to reassesscurrent security policy. Its key components are iden-tifying information that may have security relevanceand determining whether to escalate a trend or eventto the Assess phase. To determine if an event ortrend should be escalated, it must be consideredwithin the context of the organization's industry,and should be evaluated in terms of organizationalpriorities.

Identify Internal Trends. Internal trends can comefrom new business opportunities, new capabilities,or new applications. They might also arise from anexisting business or security process.

Escalate to Assess Phase. Not all changes should beescalated to the Assess phase—common sense and aset of criteria should prevail. These criteria need notbe pages of detailed considerations, but they shouldvalidate a true impetus for change. Three key issuesshould be examined: scope of impact (will thischange impact a single business unit ot will it have aglobal business impact?), timeliness (has the need forthis change been proven over time?) and momentum(is there support among key stakeholders—systemadministrators, application owners, business unitleaders —-that this change is necessary?).

The FutureAs a high-level policy management tool, PFIRESfacilitates communication between senior manage-ment and technical security management. Withimproved communication, the organization shouldrealize immediate benefits—increased protectionfrom and responsiveness to security incidents relatedto computing activities, including e-business opera-tions. By effectively managing security risks, theorganization is better positioned to successfullyachieve its objectives.

Much work remains to be done in this area. Inter-

national and regional concerns, organizationalbehavior, legal issues, supply chain factors, andindustty-specific concerns are a few areas that wouldbenefit from an in-depth exploration of relatedinformation security policy. Enhanced models andtools for analyzing and managing information secu-rity infrastructure investments are also needed. Cer-tainly, tesearch needs to be conducted into how wellthe life cycle meets the policy management needs oftoday's organizations and what improvements needto be made to ensure future success. Q

REFERENCES1. 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 Analysisand Design. Addison-Wesley, Reading, MA, 1999.

5. Lichrenstein, S. Developing Internet security policy for organizations. InProceeding of the Thirtieth Hawaii International Conference on SystemsSciences. 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 Industriesand 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 ofmanagement at the Krannert Graduate School of Management atPurdue University. Iiidian.i.SUBHAJYOTI B A N D Y O P A D H A Y (bandyos@notes.cba-ufl.cdu) is anassistant professor of Decision and ]nform;icion Sciences at theWarrington College of Business Administration at the University ofFlorida.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 Centerfor 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 forprofit or commercial advantage and that copies bear this notice and the full citation onthe first page. Tti iiipy otherwise, to republish, to post on servers or to recJJscribute tolists, requires prior specific permission and/or a fee.

© 2003 ACM 0002-0782/03/0700 15.00

rO6 July 2003/Vol 46, No 7 COMMUNtCATIONS OFTHE ACM