a method for designing secure solutions - semantic scholar · 2015-07-28 · a method for designing...

A method for designingsecure solutions

by J. J. Whitmore

The task of developing information technology(IT) solutions that consistently and effectivelyapply security principles has many challenges,including: the complexity of integrating thespecified security functions within the severalunderlying component architectures found incomputing systems, the difficulty in developing acomprehensive set of baseline requirements forsecurity, and a lack of widely accepted securitydesign methods. With the formalization ofsecurity evaluation criteria into an internationalstandard known as Common Criteria, one of thebarriers to a common approach for developingextensible IT security architectures has beenlowered; however, more work remains. Thispaper describes a systematic approach fordefining, modeling, and documenting securityfunctions within a structured design process inorder to facilitate greater trust in the operationof resulting IT solutions.

Trust is the measure of confidence that can beplaced on the predictable occurrence of an an-

ticipated event, or an expected outcome of a pro-cess or activity.

For business activities that rely on information tech-nology (IT), trust is dependent on both the natureof the agreement between the participants and thecorrect and reliable operation of the IT solution. Thereliance on computerized processes for personal,business, governmental, and legal functions is evolv-ing into a dependency and a presumption (not to beconfused with trust) that the processes, and the ITsystems within which they execute, will function with-out flaw. It is reasonable to expect that legal find-ings relative to the correct and reliable operation ofIT solutions will be the basis for whether one party

is liable for the damages suffered by another partyas a result of a computerized operation.

Trustworthiness of IT solutions can be affected bymany factors found throughout the life cycle of so-lution definition, design, deployment, and operation.The trustworthiness of design of IT solutions can beaffected by the clarity and completeness with whichthe requirements are expressed by stakeholders andinterpreted by solution designers. The trustworthi-ness of operation of IT solutions can be affected bythe trustworthiness of the components and processesupon which they are built, the accuracy with whichthe design is implemented, and the way in which theresulting computing systems are operated and main-tained. The trustworthiness of operational IT solu-tions can also be affected by the environments inwhich the solutions are positioned, by individualswho access them, and by events that occur duringtheir operational lifetime.

Given that IT components will most likely continueto have flaws, that unexpected events will most likelyoccur, and that individuals will most likely continueto seek to interfere with the operation of computingsolutions and the environmental infrastructure uponwhich the solutions rely, what can be done to instilla sufficient measure of confidence—that is, trust—inthe correct and reliable operation of a given infor-mation technology solution?

rCopyright 2001 by International Business Machines Corpora-tion. Copying in printed form for private use is permitted with-out payment of royalty provided that (1) each reproduction is donewithout alteration and (2) the Journal reference and IBM copy-right notice are included on the first page. The title and abstract,but no other portions, of this paper may be copied or distributedroyalty free without further permission by computer-based andother information-service systems. Permission to republish anyother portion of this paper must be obtained from the Editor.

IBM SYSTEMS JOURNAL, VOL 40, NO 3, 2001 0018-8670/01/$5.00 © 2001 IBM WHITMORE 747

One realistic expectation is that designers and in-tegrators of IT solutions will enlist all reasonable mea-sures to effect the correct and reliable operation ofIT solutions throughout the design, development, anddeployment phases of the solution life cycle.

While the responsibility for considering all reason-able measures is shared among all individuals in-volved in the design, development, and deploymentof every IT solution, the role of anticipating the per-ils that the IT solution may face, and ensuring thatthe business risks of IT solution operation are mit-igated, is generally the focus of IT security profes-sionals.

Information technology security is a discipline thatuntil recently was centered within the military, na-tional security organizations, and the banking indus-try. With the growth of the Internet as a core net-working and cooperative computing infrastructure,the need for, and the value of, IT security expertisehas increased dramatically. The position of today’ssecurity architect closely parallels the role of the net-work manager or operator of the early 1980s. Thesimilarities include the need to meet high expecta-tions and service levels, a limited set of tools and tech-niques, low visibility of the electronic activities withinthe operational environment, plus the challenge oftimely recognition and response to events and peril.In the mid-1980s the development of a systems man-agement discipline provided a focus, a method, anda tool set for standardized approaches to system-widedesign, operation, and management.

To date, the application of IT security countermea-sures is generally limited to addressing specific vul-nerabilities, such as applying network and systemsmanagement processes, hardening operating systemsfor publicly available servers, applying and monitor-ing intrusion detection systems, configuring and op-erating digital certificate servers, and installing andconfiguring firewalls.1

Based upon the evolution of destructive computercodes and viruses, the repeated breaches of sensi-tive computer systems, and recurring incidents ofcompromise of private information stored on net-worked computing systems, it is reasonable to con-clude that the effectiveness of security measures incomputing solutions needs to be improved. Recentlysecurity experts from government and industry ex-pressed the need for a more comprehensive ap-proach to describing security requirements and de-signing secure solutions.2

This paper documents the findings and recommen-dations of a project for which the initial objectivewas to develop training materials for a recently de-fined technical discipline, within IBM Global Services,for security architects. During the project, early at-tempts to organize and present the “prior art” deal-ing with information technology security producedincomplete and unsatisfactory results, leading to theconclusion that a more fundamental analysis wasneeded. The refocused analysis produced a thought-provoking proposal for articulating, documenting,and synthesizing security within information tech-nology solutions.

Although the project objectives were met, the by-products are different from those first envisioned.The observations and conclusions from the projectare summarized within this paper, including: an ex-amination of the basic motivations for implement-ing security, a review and recategorization of com-monly invoked security standards, an analysis of thefundamental elements of security architecture andits design, and some first attempts to render archi-tectural representations.

Problem statement

A systematic approach for applying security through-out information technology solutions is necessary inorder to ensure that all reasonable measures are con-sidered by designers, and that the resulting comput-ing systems will function and can be operated in acorrect and reliable manner.

In IBM Global Services, the requirement for a methodfor designing secure solutions is driven from severalperspectives: (1) there is a need to “grow” the com-munity of IT architects with a shared security focus,(2) there is a need to create synergy among the sev-eral technical disciplines within the IT architect pro-fession relative to security issues, and (3) there is aneed to develop consistent designs because manybusinesses and organizations have similar securityand privacy compliance requirements based uponstatute, regulation, and industry affiliation, and manyenterprises are multinational, with geographically di-verse installations operating under similar securitypolicies and practices.

To be effective, the resulting method should use ex-isting security paradigms, integrate with other infor-mation technology architectures, and work with to-day’s technologies.

WHITMORE IBM SYSTEMS JOURNAL, VOL 40, NO 3, 2001748

A logical and systematic technique for designing se-cure solutions has potential value beyond IBM GlobalServices: to individuals, by fostering trust within com-puting environments that would otherwise be sus-pect; to information technology professionals, bypromoting rigor within an emerging discipline ofcomputing science; and to enterprises, by providinga technical standard with which the effectiveness ofinformation technology designs, and designers, canbe evaluated.

Analysis

Information technology architects rely on a widerange of techniques, tools, and reference materialsin the solution design process. The results of a de-sign activity may include an operational computingsystem or a set of documents that describe the sys-tem to be constructed from one or more viewpointsand at different levels of granularity. The documentsprovide a visualization of the system architecture.

To arrive at a system architecture, architects may usepersonal experience, or they may rely upon docu-mented systematic procedures or methods. In ad-dition to methods, architects refer to prior work andemploy data collection techniques to define the prob-lem space and the solution space. Reference mate-rials can include a taxonomy of the problem space,a catalog of solution requirements, and documentedmodels, patterns, or integrated solution frameworks.In general, as the definition of a given problem spacematures, the taxonomy of the solution requirementsstabilizes. This leads to well-defined reference mod-els, proven solution frameworks, and mature solu-tion design methods.3

IT security architecture fits this model for limitedproblem spaces such as securing a network perim-eter, where a set of solution requirements can be de-fined. A solution framework can be constructed foran enterprise firewall, and a solution architecture canbe documented using known reference models for“demilitarized zones.” IT security does not, in gen-eral, fit this model, because: (1) the security prob-lem space has not stabilized in that the number andtype of threats continue to grow and change, (2) ex-isting security solution frameworks take a limitedview of the problem space, as with firewalls4 and net-work-level security,5 and (3) methods for creatingsecurity solution architectures are generally confinedto the defined solution frameworks. For ill-definedproblem spaces like IT security, the path to maturity

of models and methods requires a different ap-proach.3

Security-specific taxonomies, models, and methods.ISO (International Organization for Standardization)7498-26 is a widely referenced document associatedwith IT security solution design. Its purpose is to ex-tend the applicability of the seven-layer OSI (OpenSystems Interconnection) system model to cover se-cure communication between systems. Section 5 ofthis document describes a set of security services andmechanisms that could be invoked at the appropri-ate layer within the OSI system model, in appropri-ate combinations to satisfy security policy require-ments. Section 8 documents the need for ongoingmanagement of OSI security services and mecha-nisms, to include management of cryptographic func-tions, network traffic padding, and event handling.

Many security practitioners use the OSI security ser-vices—authentication, access control, data confiden-tiality, data integrity, and nonrepudiation—as thecomplete taxonomy for the security requirements forIT solutions. However, the preamble of ISO 7498-2specifically states that “ . . . OSI security is not con-cerned with security measures needed in end systems,installations, and organizations, except where thesehave implications on the choice and position of se-curity services visible in OSI. These latter aspects ofsecurity may be standardized but not within the scopeof OSI Recommendations.”

Security evaluation criteria. Agencies and standardsbodies within governments of several nations havedeveloped evaluation criteria for security within com-puting technology. In the United States the docu-ment has the designation “Trusted Computer SystemSecurity Evaluation Criteria,” or TCSEC. The EuropeanCommission has published the Information Technol-ogy Security Evaluation Criteria, also known as ITSEC,and the Canadian government has published the Ca-nadian Trusted Computer Product Evaluation Crite-ria, or CTCPEC. In 1996, these initiatives were officiallycombined into a document known as the Common Cri-teria, or CC.7 In 1999 this document was approved asa standard7–9 by the International Organization forStandardization. This initiative opens the way to world-wide mutual recognition of product evaluation results.

Common Criteria. Common Criteria provide a tax-onomy for evaluating security functionality througha set of functional and assurance requirements. TheCommon Criteria include 11 functional classes of re-quirements: security audit, communication, crypto-

IBM SYSTEMS JOURNAL, VOL 40, NO 3, 2001 WHITMORE 749

graphic support, user data protection, identificationand authentication, management of security func-tions, privacy, protection of security functions, re-source utilization, component access, and trustedpath or channel. These 11 functional classes are fur-ther divided into 66 families, each containing a num-ber of component criteria. There are approximately130 component criteria currently documented, withthe recognition that designers may add additionalcomponent criteria to a specific design. There is aformal process for adopting component criteriathrough the Common Criteria administrative body(www.commoncriteria.org).

Governments and industry groups are developingfunctional descriptions for security hardware andsoftware using the Common Criteria. These docu-ments, known as protection profiles,10 describegroupings of security functions that are appropriatefor a given security component or technology. Theunderlying motivations for developing protectionprofiles include incentives to vendors to deliver stan-dard functionality within security products and re-duction of risk in information technology procure-ment. In concert with the work to define protectionprofiles, manufacturers of security-related computersoftware and hardware components are creating doc-umentation that explains the security functionalityof their products in relation to accepted protectionprofiles. These documents are called “security tar-gets.” Manufacturers can submit their products andsecurity targets to independently licensed testing fa-cilities for evaluation in order to receive compliancecertificates.

Common Criteria as a taxonomy for requirements andsolutions. The security requirements defined withinthe Common Criteria have international support as“best practices.” Common Criteria are intended asa standard for evaluation of security functionality inproducts. They have limitations in describing end-to-end security—because the functional require-ments apply to individual products, their use in acomplex IT solution is not intuitive.11 Protection pro-files aid in the description of solution frameworks,although each protection profile is limited in scopeto the specification of functions to be found in a sin-gle hardware or software product.

Common Criteria as a reference model. The CommonCriteria introduce few architectural constructs:8 thetarget of evaluation, or TOE, represents the compo-nent under design; and the TOE security functionsdocument, or TSF, represents that portion of the TOE

responsible for security. Under Common Criteria,the system or component under consideration is a“black box”; it exhibits some security functionalityand some protection mechanisms for the embeddedsecurity functions.

Summary of analysis. For well-understood problemspaces, methods document the prior work and pro-vide best practices for future analysis. For changingproblem spaces such as IT security, methods can onlypostulate a consistent frame of reference for prac-titioners in order to encourage the development offuture best practices. With time and experience themethods and models associated with IT security willmature.

The Common Criteria document has importantvalue to the security community, given its history andacceptance as a standard for security requirementsdefinition, and its linkage to available security tech-nologies through documented protection profiles andsecurity targets. Common Criteria do not provideall of the guidance and reference materials neededfor security design.

To develop an extensible method for designing se-cure solutions, additional work is required to devel-op:

1. A system model that is representative of the func-tional aspects of security within complex solutions

2. A systematic approach for creating security ar-chitectures based on the Common Criteria re-quirements taxonomy and the corresponding se-curity system model

System model for security

Eberhardt Rechtin12 suggests an approach for de-veloping an architecture, differentiating between the“system” (what is built), the “model” (a descriptionof the system to be built), the “system architecture”(the structure of the system), and the “overall ar-chitecture” (an inclusive set consisting of the systemarchitecture, its function, the environment withinwhich it will live, and the process used to build andoperate it).

For the purposes of this project, the type of IT so-lutions addressed is consistent with a networked in-formation system (NIS).13 Furthermore, the overallarchitecture is represented by the security architec-ture found within an NIS, and the security architec-


ture is represented by the structure of a security sys-tem model. With a generalized system model forsecurity in an NIS environment, architects could cre-ate instances of the system model, based upon de-tailed functional and risk management requirements.

Rechtin outlines the steps for creating a model asfollows: (1) aggregating closely related functions, (2)partitioning or reducing the model into its parts, and(3) fitting or integrating components and subsystemstogether into a functioning system. The security sys-tem model will be represented by the aggregationof security functions, expressed in terms of sub-systems and how the subsystems interact. The secu-rity-related functions within an NIS can be describedas a coordinated set of processes that are distributedthroughout the computing environment. The notionof distributed security systems, coordinated by de-sign and deployment, meets the intuitive expecta-tion that security within an NIS should be consideredpervasive. In an NIS environment, security subsystemsmust be considered as abstract constructs in orderto follow Rechtin’s definition.

For this project, Common Criteria were consideredto be the description of the complete function of thesecurity system model. The classes and familieswithin the Common Criteria represent an aggrega-tion of requirements; however, after careful review,it was determined that the class and family structuresdefined within Common Criteria do not lend them-selves to be used as part of a taxonomy for pervasivesecurity. The aggregation is more reflective of ab-stract security themes, such as cryptographic oper-ations and data protection, rather than security inthe context of IT operational function. To suit theobjective of this project, the Common Criteria func-tional criteria were re-examined and reaggregated,removing the class and family structures. An anal-ysis of the 130 component-level requirements in re-lation to their function within an NIS solution sug-gests a partitioning into five operational categories:audit, access control, flow control, identity and cre-dentials, and solution integrity. A summary mappingof CC classes to functional categories is provided inTable 1.

While redundancy is apparent at the class level, thereis only a small overlap at the family level of the hi-erarchy defined within Common Criteria and below.Much of the overlap represents the intersection offunction and interdependency among the categories.

Security subsystems. The component-level guidanceof Common Criteria documents rules, decision cri-teria, functions, actions, and mechanisms. This struc-ture supports the assertion that the five categoriesdescribed in Table 1 represent a set of interrelatedprocesses, or subsystems, for security. The notion ofa security subsystem has been proposed previously;the authors of Trust in Cyberspace13 described func-tions within operating system access control compo-nents as belonging to a decision subsystem or an en-forcement subsystem.14 The five interrelated securitysubsystems proposed here expand the operating sys-tem-based concept and suggest that function and in-terdependency of security-related functions, beyondcentralized access control, can be modeled as well.(See Figure 1.)

A brief description of each of the five security sub-systems, along with further detail of the aggregationof CC component-level criteria within each sub-system, is now provided. The subsystem diagrams arerepresented as parts of a closed-loop control systemshowing the internal processes that each performs,along with its external interfaces. In this represen-tation, each subsystem consists of a managing pro-cess with a default idle state and several executionpaths that can be invoked either by an asynchronousrequest signaled by another security subsystem orby a synchronized request from a nonsecurity pro-

Table 1 Placing Common Criteria classes in functionalcategories

FunctionalCategory

Common Criteria Functional Class

Audit Audit, component protection,resource utilization

Access control Data protection, componentprotection, security management,component access, cryptographicsupport, identification andauthentication, communication,trusted path/channel

Flow control Communication, cryptographicsupport, data protection,component protection, trustedpath/channel, privacy

Identity/credentials Cryptographic support, dataprotection, component protection,identification and authentication,component access, securitymanagement, trusted path/channel

Solution integrity Cryptographic support, dataprotection, component protection,resource utilization, securitymanagement


cess. Complementary representations composed ofcomponent views and interaction diagrams for thesubsystems are being developed.

Security audit subsystem. The purpose of the secu-rity audit system in an IT solution is to address thedata collection, analysis, and archival requirementsof a computing solution in support of meeting thestandards of proof14 required by the IT environment.A security audit subsystem is responsible for captur-ing, analyzing, reporting, archiving, and retrievingrecords of events and conditions within a comput-ing solution. This subsystem can be a discrete set ofcomponents acting alone, or a coordinated set ofmechanisms among the several components in thesolution. Security audit analysis and reporting caninclude real-time review, as implemented in intru-sion detection components, or after-the-fact review,as associated with forensic analysis in defense of re-pudiation claims. A security audit subsystem may relyupon other security subsystems in order to manageaccess to audit-related systems, processes, and data,control the integrity and flow of audit information,and manage the privacy of audit data. From Com-mon Criteria, security requirements for an audit sub-system would include:

● Collection of security audit data, including captureof the appropriate data, trusted transfer of auditdata, and synchronization of chronologies

● Protection of security audit data, including use oftime stamps, signing events, and storage integrityto prevent loss of data

● Analysis of security audit data, including review,anomaly detection, violation analysis, and attackanalysis using simple heuristics or complex heu-ristics

● Alarms for loss thresholds, warning conditions, andcritical events

The closed loop process for a security audit sub-system is represented in Figure 2.

Solution integrity subsystem. The purpose of the so-lution integrity subsystem in an IT solution is to ad-dress the requirement for reliable and correct op-eration of a computing solution in support of meetingthe legal15 and technical standard for its processes.A solution integrity subsystem can be a discrete setof components or a coordinated set of mechanismsamong the several components in the solution. Thesolution integrity subsystem may rely upon the au-dit subsystem to provide real-time review and alertof attacks, outages, or degraded operations, or after-the-fact reporting in support of capacity and perfor-mance analysis. The solution integrity subsystem mayalso rely upon the other subsystems to control ac-cess and flow. From Common Criteria, the focus ofa solution integrity subsystem could include:

● Integrity and reliability of resources● Physical protections for data objects, such as cryp-

tographic keys, and physical components, such ascabling, hardware, etc.

● Continued operations including fault tolerance,failure recovery, and self-testing

● Storage mechanisms; cryptography and hardwaresecurity modules

● Accurate time source for time measurement andtime stamps

● Prioritization of service via resource allocation orquotas

● Functional isolation using domain separation ora reference monitor

● Alarms and actions when physical or passive at-tack is detected

The closed loop process for a solution integrity sub-system is represented in Figure 3.

Access control subsystem. The purpose of an accesscontrol subsystem in an IT solution is to enforce se-curity policies16 by gating access to, and executionof, processes and services within a computing solu-

Figure 1 IT security processes and subsystems

MANAGEACCESS CONTROL

MANAGEIDENTITIES ANDCREDENTIALS

MANAGEINFORMATIONFLOW

MANAGESECURITYAUDIT

MANAGESOLUTIONINTEGRITY


tion via identification, authentication, and authoriza-tion processes, along with security mechanisms thatuse credentials and attributes. The credentials andattributes used by the access control subsystem alongwith the identification and authentication mecha-nisms are defined by a corresponding credential sub-system. The access control subsystem may feed eventinformation to the audit subsystem, which may pro-vide real-time or forensic analysis of events. The ac-cess control subsystem may take corrective actionbased upon alert notification from the security au-dit subsystem. From Common Criteria, the func-tional requirements for an access control subsystemshould include:

● Access control enablement● Access control monitoring and enforcement● Identification and authentication mechanisms, in-

cluding verification of secrets, cryptography (en-cryption and signing), and single- vs multiple-useauthentication mechanisms

● Authorization mechanisms, to include attributes,privileges, and permissions

● Access control mechanisms, to include attribute-based access control on subjects and objects anduser-subject binding

● Enforcement mechanisms, including failure han-dling, bypass prevention, banners, timing and time-out, event capture, and decision and logging com-ponents

The closed loop process for an access control sub-system is represented in Figure 4.

Information flow control subsystem. The purposeof an information flow control subsystem in an ITsolution is to enforce security policies16 by gating theflow of information within a computing solution,affecting the visibility of information within a com-puting solution, and ensuring the integrity of infor-mation flowing within a computing solution. The in-formation flow control subsystem may depend upon

Figure 2 Security audit subsystem processes

COLLECT SECURITYAUDIT DATA

GENERATE SECURITY AUDITREPORTS

SIGNALED SECURITY AUDIT SYSTEM ANOMALY

INTEGRITYCHECK REQUEST

TIME-BASEDAUDIT EVENT

TRANSFER SECURITY AUDIT DATA

SIGN AND TIME-STAMP SECURITY AUDIT DATA

ANALYZE SECURITYAUDIT DATA

ARCHIVE SECURITY AUDIT DATA

REQUESTTRUSTED TIME

MANAGESECURITYAUDIT

SIGNALANOMALYEVENTS

GENERATESECURITYAUDIT DATA

SIGNALTIME-BASEDEVENTS


trusted credentials and access control mechanisms.This subsystem may feed event information to thesecurity audit subsystem, which may provide real-time or forensic analysis of events. The informationflow control subsystem may take corrective actionbased upon alert notification from the security au-dit subsystem. From Common Criteria, an informa-tion flow control subsystem may include the follow-ing functional requirements:

● Flow permission or prevention● Flow monitoring and enforcement● Transfer services and environments: open or

trusted channel, open or trusted path, media con-versions, manual transfer, import to or export be-tween domains

● Mechanisms observability: to block cryptography(encryption)

● Storage mechanisms: cryptography and hardwaresecurity modules

● Enforcement mechanisms: asset and attributebinding, event capture, decision and logging com-ponents, stored data monitoring, rollback, resid-ual information protection and destruction

The closed loop process for an information flow con-trol subsystem is represented in Figure 5.

Identity or credential subsystem. The purpose of acredential subsystem in an IT solution is to gener-ate, distribute, and manage the data objects that con-vey identity15 and permissions across networks andamong the platforms, the processes, and the secu-rity subsystems within a computing solution. In someapplications, credential systems may be required toadhere to legal criteria15 for creation and mainte-

Figure 3 Integrity subsystem processes

INTEGRITYSUBSYSTEMAUDIT REQUEST

TIME-BASEDASSURANCEEVENT

SIGNALEDINTEGRITYSYSTEM ANOMALY

REQUESTTRUSTED TIME

CONFIRMCOMPONENT ANDDATA INTEGRITY

TRANSFER SIAUDIT DATA

SIGN AND TIME-STAMP SI AUDIT DATA

ENSUREDOMAINSEPARATION

PROVIDE CURRENTTRUSTED TIME

MAINTAINTRUSTEDTIME

MONITORCOMPONENTRELIABILITY

MANAGESOLUTIONINTEGRITY (SI)

SIGNALANOMALYEVENTS

GENERATE SIAUDIT DATA

SIGNALTIME-BASEDEVENTS

VERIFY CORRECTOPERATION


nance of trusted identity used within legally bindingtransactions.

A credential subsystem may rely on other subsystemsin order to manage the distribution, integrity, andaccuracy of credentials. A credential subsystem has,potentially, a more direct link to operational bus-iness activities than the other security subsystems,owing to the fact that enrollment and user supportare integral parts of the control processes it contains.From Common Criteria, a credential subsystem mayinclude the following functional requirements:

● Single-use vs multiple-use mechanisms, either cryp-tographic or noncryptographic

● Generation and verification of secrets● Identities and credentials to be used to protect

security flows or business process flows

● Identities and credentials to be used in protectionof assets: integrity or nonobservability

● Identities and credentials to be used in access con-trol: identification, authentication, and access con-trol for the purpose of user-subject binding

● Credentials to be used for purposes of identity inlegally binding transactions

● Timing and duration of identification and authen-tication

● Life cycle of credentials● Anonymity and pseudonymity mechanisms

The closed loop process for a credential subsystemis represented in Figure 6.

Summary of the security system model. This studypostulates that the five security subsystems describedhere exist within every IT solution at the conceptual

Figure 4 Access control subsystem processes

INVOKE PROCESSINTERFACE

SIGN AND TIME-STAMP ACCESS CONTROL AUDIT DATA

INVOKE PROCESSINTERFACE

MAINTAIN SESSIONSTATE

SIGNALED ACCESS CONTROL ANOMALY

REQUEST TOINVOKE/ACCESSA PROCESS

TIME-BASEDACCESSCONTROL EVENT

DISABLE USER/SUBJECT BINDING

ENABLE USER/SUBJECTBINDING

CHECK ACCESSCONTROLRULES

IDENTIFY ANDAUTHENTICATEREQUESTER

VERIFY SECRETS

REJECT ACCESSCONTROLREQUEST

CHECKCREDENTIALSTATUS

TRANSFERACCESS CONTROLAUDIT DATA

OBTAINCREDENTIAL

MAKE ACCESSCONTROLDECISIONS

CLEAR SESSIONSTATE

SIGNAL ACCESSCONTROLANOMALY EVENT

MANAGEACCESSCONTROL

GENERATEACCESS CONTROLAUDIT DATA


level, and that the design, integration, and interwork-ing of the services and mechanisms associated withthese subsystems represent the security functional-ity of the solution. This “security system model”needs to be combined with a method for developingthe detailed security architecture for a given IT so-lution.

A systematic approach to developingsecurity architectures

A system architecture has been defined as “the struc-ture of the system to be built.” In this study, the “sys-tem to be built” consists of the security control sys-

tem found within a networked information system.Figure 7 represents the solution environment. Herean e-business computing solution serves informationor supports electronic commerce transactions via theInternet. The e-business computing solution is op-erated by an enterprise and provides services to oneor more user communities.

The e-business computing solution can be describedas a set of automated business processes supportingthe business context that requires security assurancesand protections. The design goal is to infuse secu-rity into the computing solution and the related ITenvironment.

Figure 5 Information flow control subsystem processes

SIGNALED INFOFLOW CONTROLANOMALY

REQUEST TOACCESS DATA

TIME-BASEDINFO FLOW CONTROL EVENT

REQUEST TOTRANSFER DATA

DISABLE FLOW

ENABLE INFORMATIONFLOW:SEND/RECEIVEREAD/WRITEIMPORT/EXPORT

CHECK IFC RULES

IDENTIFY AND AUTHENTICATE ORIGIN/RECIPIENT

MAP IDENTIFIERSTO IDENTITIES

INVOKE FLOW INTERFACE

CHECK VALIDITY OF IDENTITIES

TRANSFER IFC AUDIT DATA

OBTAIN ORIGIN/RECIPIENT IDENTIFIER/IDENTITY

MAKE IFC DECISIONS

APPLY FLOWCONTROLMECHANISMS

SIGN AND TIME-STAMP IFC AUDIT DATA

MANAGE INFORMATIONFLOW

CLEAR STATE

DATA INTEGRITYPRIVACYTRUSTED PATHTRUSTED CHANNELPROOF-OF-ORIGINPROOF-OF-RECEIPT SECURITY ATTRIBUTESIMMOVABILITYDOMAIN CROSSSTATIC VALIDATIONCONTENT SCAN/FILTER

REJECT INFORMATIONFLOW REQUEST

SIGNAL IFC ANOMALY EVENT

GENERATE IFC AUDIT DATA


From a business perspective, there are two objec-tives: (1) to ensure that the desired IT business pro-cess flow yields correct and reliable results, and (2)to ensure that the potential vulnerabilities and ex-ception conditions (i.e., perils) within IT business pro-cess flows are addressed in ways that are consistentwith the risk management objectives. These objec-tives show the duality of security design: to supportand assure normal flows, as well as identify and ac-count for all illicit flows and anomalous events.

Business process model. Figure 8 represents IT pro-cess flows for a generalized business system. The pro-

cess flows reflect the events and conditions in whichinformation assets are acted upon by processes thatare invoked by users, or by processes acting on be-half of users. The left arrow represents the modelbusiness flow within a trusted environment, and theright arrow represents a more realistic view of thebusiness flow, where perils exist in the operating envi-ronment.

Security design objectives. Traditionally, security re-quirements have been expressed by referencing thesecurity services within the OSI model:6 authentica-tion, access control, data confidentiality, data integ-

Figure 6 Credential subsystem processes

SIGNAL CREDENTIALANOMALY EVENT

REQUEST FORALIAS/PSEUDONYM

REQUEST FOR CREDENTIALSTATUS

REQUEST FORCREDENTIALMAPPING

ENROLL/RENEWUSER

REQUEST FORCREDENTIALREPLICA

SUSPEND/REVOKECREDENTIAL

VALIDATECREDENTIALREQUEST

VALIDATEMAPPING/ALIASREQUEST

OBTAINAPPROVAL

GENERATEAND PROTECTSECRETS

REJECT CREDENTIALREQUEST

VERIFYSECRETS

TRANSFERCREDENTIALAUDIT DATA

VALIDATEENROLLMENT INFORMATION

CREATE/ENABLECREDENTIAL

PUBLISHCREDENTIAL

SIGNALED CREDENTIAL ANOMALY

TIME-BASEDCREDENTIALEVENT

DISTRIBUTECREDENTIAL

RETURNCREDENTIALSTATUS

SIGN AND TIME-STAMPCREDENTIALAUDIT DATA

PUBLISHSTATUS

GENERATECREDENTIALAUDIT DATA

ASSIGNCREDENTIAL/ALIAS

CAPTUREENROLLMENTINFORMATION

MANAGECREDENTIALS


rity, and nonrepudiation. This practice introducesambiguity when applied in the context of businessprocesses. This ambiguity can contribute to a mis-communication of security requirements and a mis-match of functionality within the computing solution.As with other architecture disciplines, the technicalobjectives of the security design activity need to bearticulated in quantifiable terms. Specific design ob-jectives need to be developed and validated for eachsolution. For reference in this project, the followingset of security design objectives were derived as aresult of an analysis of the security-incident handlingand reporting system for one corporation:

1. There is a need to control access to computer sys-tems and their processes, consistent with definedroles and responsibilities.

2. There is a need to control access to information,consistent with information classification and pri-vacy policies.

3. There is a need to control the flow of informa-tion, consistent with information classification andprivacy policies.

4. There is a need to manage the reliability and in-tegrity of components.

5. There is a need for protections from maliciousattack.

6. There is a need for trusted identity to address therequirement of accountability of access to systems,processes, and information.

7. There is a need to prevent fraud within businessprocesses and transactions, or to detect and re-spond to attempted fraud.

Selection and enumeration of subsystems. The se-curity design objectives and the solution environmenthave a central role in the selection and enumerationof subsystems. Table 2 shows a possible mapping ofthe example design objectives to security subsystems.It indicates where a subsystem may be required (R)

Figure 7 Networked information system environment

EMPLOYEE

BUSINESSDATA

BUSINESSAPPLICATION

INFORMATIONSERVER ORE-COMMERCEPORTAL

CORPORATION

INDIVIDUALCUSTOMER

SUPPLIERS

GENERAL POPULATION

INTERNET

E-BUSINESS COMPUTING SOLUTION


or supplementary (S) in satisfying an individual se-curity requirement. Actual subsystem selection re-quires documented rationale.

There are many interrelated factors that determinehow many instances of a given subsystem appear inthe solution. Table 3 suggests motivations for instan-

Table 2 Mapping design objectives to security subsystems

Security Design Objectives Audit Integrity AccessControl

FlowControl

Credentials/Identity

Control access to systems/processes S S R S SControl access to information S S S R RControl the flow of information S S S R SCorrect and reliable component operation S R S S SPrevent/mitigate attacks R R R R SAccountability through trusted identity R R S S RPrevent/mitigate fraud R R R R R

Figure 8 The normal and peril IT business process flow

USERS ORPROCESSES

ACTING IN AUTHORIZED ROLES

IDENTITY ANDPERMISSIONS

IN ORDER TO IDENTITY ANDPERMISSIONS

IN ORDER TO

AUTHORIZATION TO

INVOKE ORCOMMUNICATEWITH

PROCESSES THAT

ACCESS OPERATE UPON TRANSFERDISTRIBUTE

ACCESS OPERATE UPON TRANSFERDISTRIBUTE

INFORMATIONASSETS

REQUEST ANDRECEIVE

ACTING IN ROLES (EITHER)

CREDENTIALS THAT CONVEYACQUIRE,PRESENT,AND USE

CREDENTIALS THAT CONVEYACQUIRE,PRESENT,AND USE

REQUEST ANDRECEIVEOR CIRCUMVENT

AUTHORIZATION TO

INVOKE ORCOMMUNICATE WITHOR OBSERVE FLOWSRELATED TO

PROCESSES THAT

INFORMATIONASSETS

USERS ORPROCESSESOR OTHERS

AUTHORIZEDOR UNAUTHORIZED


tiating security subsystems within a design. Actualsubsystem enumeration requires documented ratio-nale.

Documenting conceptual security architecture.Given the agreed-upon design objectives, a concep-tual model for security within the IT solution can becreated. Figures 9A and 9B represent a conceptualsecurity architecture. For clarity, security functionshave been grouped by design objective.

The diagrams represent the solution environmentsegmented by risk profile or operational affinity,along with icons for security functions. The legendfor the diagrams maps the security subsystems toicons. The information flow control subsystem hasa wide range of functions. For this reason, a rect-angle is used to indicate a policy evaluation and en-forcement function, whereas an oval indicates a dataflow function, such as a communication protocol withsecurity capabilities.

From the perspective of the enterprise deploying thesolution, the security design objectives will dictatewhere security functionality is desired; however, thecompliance to some or all of the security require-ments may be limited by the enforceability of pol-icies beyond the boundaries of the enterprise.Whether and how these credential subsystems andaccess control subsystems can be integrated into thesecurity architecture can have a major impact on thetrustworthiness of the solution as a whole. These is-sues and dependencies should be considered anddocumented within architectural decisions.

This type of conceptual model forms the baselinefor developing and evaluating a “proof-of-concept”and further refinement of the functional aspects ofsecurity within the target environment.

Integrating security into the overall solutionarchitecture

There are several steps involved in translating theconceptual security subsystem functions into com-ponent-level specifications and integration guidance.These include: creating models of the solution envi-ronment, documenting architectural decisions, de-veloping use cases, refining the functional design, andintegrating security requirements into component ar-chitectures.

Solution models. Creating an initial solution modelis a critical step in the design process. With skill andexperience, one-of-a-kind solution models can be de-veloped to fit a given set of requirements. For com-plex solutions, the practice of using templates de-rived from prior solutions is becoming commonplace.

The Enterprise Solutions Structure (ESS) providesa range of reference architectures17 for e-businesssolutions.

Documenting architectural decisions. Previously, thenotion of the duality of security design was described,that is, ensuring correct and reliable operation andprotecting against error and maliciousness. Both mo-tivations are based upon managing the business risksof the solution and of the environment. Risks rep-

Table 3 Determining the security subsystems in a design

Subsystem Number ina Design

Characteristics of the Computing Environment

Security audit subsystem Few One subsystem for archive of related critical dataOne subsystem for analysis of related anomaliesOne subsystem for fraud detection in the solution

Integrity Few One subsystem per group of related critical componentsAccess control 1 to n One subsystem per unique user-subject binding mechanism

or policy rule setFlow control 1 to m One subsystem per unique flow control policy rule set

One or more flow control functions per OSI layer service:physical, datalink, network, end-to-end transport,application

One or more flow control functions per domain boundaryCredentials/identity 1 to k Some number of credential systems per domain

Some number of credential classes per domainSome number of disparate credentials or uses for credentials

per domainSome number of aliases/pseudonyms at domain boundaries


resent the likelihood that an undesirable outcomewill be realized from a malicious attack, unexpectedevent, operational error, etc. Risks are either ac-cepted as a cost of operation, transferred to someother party, covered by liability insurance, or mit-igated by the security architecture.

Architectural decisions will dictate how robust thesecurity system architecture should be, which secu-rity subsystems to incorporate into the system archi-tecture, which functions and mechanisms within eachsubsystem should be deployed, where the mecha-nisms will be deployed, and how the deployment willbe managed.

Examples of architectural decisions include:

● Viability of the countermeasures, including thethreats addressed, the limitations and caveats ofthe solution, and the resulting window of risk

● Extensibility of the design, including whether ornot the design will serve the total population andif there will be separate designs for defined pop-ulation segments

● Usability of the design, including whether or notthe mechanisms integrate with the technology baseand the extent of the burden of compliance forusers

● Manageability of the design, including the extentof the burden of life-cycle management

Use cases. Architectural decisions will also drive theevaluation of prototypes and models of functions

EMPLOYEE

CORPORATION

INDIVIDUALCUSTOMER

SUPPLIERS

GENERAL POPULATION

BUSINESSDATA

BUSINESSAPPLICATION


INFORMATION FLOW CONTROL FUNCTIONS

ACCESS CONTROLFUNCTIONS

SECURITY AUDITFUNCTIONS

SOLUTION INTEGRITYFUNCTIONS

Figure 9A Defending against attacks: Flow control interfaces, access control, audit and integrity functions within networked information system environments

INTERNET


within the solution. One form of prototype is calleda use case. Both security threats and normal inter-actions and flows can be validated with use cases.

Example 1: Interception of errant packet or messageflow. Figure 10 represents several levels of detail forthe operation of an information flow control sub-system that is designed to monitor send and receiveoperations that cross a boundary between two net-works. The computer systems are represented in thephysical view. In the component view, an informa-tion flow control interface, positioned betweensource and destination, will examine one or moreaspects of packets or messages sent across the bound-ary. Some components of this information flow con-

trol subsystem are shown in the logic view, wherethe monitored conditions and the programmed ac-tions are carried out, based upon a set of rules.

Valid packets are allowed to flow across the bound-ary; however, packets or messages of a specified for-mat, or from an invalid source, or to an invalid des-tination, are disabled by the security subsystem. Arecord of the event is generated by invoking an in-terface to a security audit subsystem.

This example is representative of the type of filter-ing, analysis, and response that is performed withinpacket filter firewalls, or electronic mail gateways.

Figure 9B Ensuring correct and reliable operation: Access control interfaces, flow control protection mechanisms, credentials, security audit, and solution integrity functions within networked information system environments

CORPORATION

INDIVIDUALCUSTOMER

SUPPLIERS

GENERAL POPULATION

INFORMATION FLOW CONTROL FUNCTIONS

ACCESS CONTROLFUNCTIONS

CREDENTIALFUNCTIONS

SOLUTION-INTEGRITYFUNCTIONS

SECURITY AUDITFUNCTIONS

INTERNET

IT SECURITY INFRASTRUCTURE

EMPLOYEE

BUSINESSDATA

BUSINESSAPPLICATION


CREDENTIALSERVER

SECURITYREPOSITORIES

SYSTEMSMANAGEMENTSERVER


There are many architectural decisions to be eval-uated within each iteration of the design. The effecton performance due to processing delays, plus theeffect of data collection and analysis on the overalloperation of the solution, are significant factors.

Example 2: Three-tier client/server input flow. Figure11 illustrates an input flow for a three-tierclient/server process that is typical of the integrationof enterprise computing with the Internet environ-ment. Several instances of security subsystems aredepicted, spread among three network security do-mains. An information flow control subsystem is po-sitioned at the boundary points between networks.An access control subsystem is positioned betweena receiving component and its corresponding appli-cation component. Interfaces to related credentialsubsystems and security audit subsystems are shownin the security subsystem logic view. No integrity sub-system functions are referenced in this example. Thescenario follows:

1. The business process interface is invoked by a useror a process and the request is transferred via asending component.

2. The request flows across a security domain in amanner that is acceptable to the sending and re-ceiving components, based upon the defined in-formation flow control rules.

3. Identification, authentication, and access controldecisions are made based upon the external iden-tity associated with the request by an access con-trol subsystem associated with the middle-tier ap-plication.

4. The middle-tier application is invoked via a user-subject binding. The actual processing is not cov-ered here—it may include business presentationand data mapping logic, or it may be performedby an application-level information flow controlsubsystem, such as a proxy server.

5. The middle-tier application initiates, or relays, arequest to the end-tier application. The request

Figure 10 Boundary flow control with security subsystems

PHYSICAL VIEW

COMPONENT VIEW

SECURITY SUBSYSTEM LOGIC VIEW

PACKET/MESSAGE

SENDINGCOMPONENT

RECEIVINGCOMPONENT

POLICY RULES

SECURITY DOMAINBOUNDARY

INFORMATIONFLOW CONTROLINTERFACE

AUDITGENERATOR

ERRORHANDLER

POLICYEVALUATOR

FLOWENABLER


is scrutinized at another network boundary con-trol point.

6. At the end-tier application, an access control de-cision may be performed on the request relativeto the identity of the user represented by the mid-dle-tier application, depending on the design ofthe application and the exchange protocols used.

7. The business process is invoked by a user-subjectbinding if the access control decision is positive.

This demonstrates how security functions from sev-eral subsystems are distributed throughout the so-lution. As with the first example, architectural deci-sions will guide the design of the security subsystem

Figure 11 Three-tier client/server input flow with security subsystems

PHYSICAL VIEW

COMPONENT VIEW

MIDDLE TIERAPPLICATIONCOMPONENT

SENDINGCOMPONENT

DATA

RECEIVINGCOMPONENT

END-TIERAPPLICATIONCOMPONENT

PACKET/MESSAGE

SENDINGCOMPONENT

RECEIVINGCOMPONENT





ACCESSCONTROLINTERFACE

ACCESSCONTROLINTERFACE

POLICYRULES

FLOWENABLER

AUDITGENERATOR

ERRORHANDLER

FLOWPOLICYEVALUATOR

POLICYRULES

BINDINGENABLER

AUDITGENERATOR

STATEMANAGER

ERRORHANDLER

ACCESS POLICYEVALUATOR


CREDENTIALVALIDATORCREDENTIALVALIDATOR

POLICYRULES

FLOWENABLER

AUDITGENERATOR

ERRORHANDLER

FLOWPOLICYEVALUATOR

POLICYRULES

BINDINGENABLER

AUDITGENERATOR

STATEMANAGER

ERRORHANDLER



CREDENTIALVALIDATORCREDENTIALVALIDATOR

SECURITY SUBSYSTEM LOGIC VIEW


functions, which in turn may put constraints on theoverall business flow in order to achieve the risk man-agement objectives.

Refining the functional design. Walk-throughs ofcomplete business processes, including exceptionconditions and handling processes, assist in creat-ing a viable solution outline and refining require-ments and interdependencies among the solutionbuilding blocks.

Example 3: PKI digital certificate enrollment. This ex-ample uses the credential subsystem model to de-scribe the generalized flow for enrolling a user intoan identity or credential system based upon PKI dig-ital certificates18 as the first step in developing a se-curity system architecture. The process involves com-bining the subsystem model with assumptions aboutthe business environment, the business processes, therisk management requirements, the technical spec-ifications, and possibly the legal and business com-pliance requirements16 associated with issuing PKIdigital certificates.

In Figure 12, the yellow blocks represent manual pro-cesses, the blue blocks map to automated processes,and the peach blocks map to automated audit datacapture points. The blue data storage icons repre-sent sensitive repositories, the pink icons map tocryptographic secrets, the white icons representunique contents of the certificate, and the lavendericon is associated with the certificate.

The enrollment process flow depicted demonstratesthe exchange of sensitive user information and se-crets, plus the export of the credential outside thecontrol of the issuer. The full enrollment scenarioshould include processes from a corresponding in-formation flow control subsystem. For public key cre-dentials, the format of certificates, along with detailsof how the credentials are formatted, transported,and stored are important design considerations. Allscenarios must be validated against existing and pro-posed business processes. Validation of the scenar-ios substantiates the architectural decisions discussedearlier. Subsequent design steps are needed to de-velop and map the functions of the security sub-systems to Common Criteria specifications and ul-timately onto the nodes and physical components.

Integrating security requirements into componentarchitectures. The security functions within the de-sign need to be apportioned throughout the solu-tion. However, many of the mechanisms and services

within the IT solution that implement security func-tionality operate within other than security compo-nents, for example: database systems, application sys-tems, clients, servers, and operating systems. The taskof adopting security function into the network, ap-plication, middleware, security, systems manage-ment, and infrastructure architectures is shared bythe several architects and integration specialists in-volved in the design project. The process involves astructured approach, considering the purposeful al-location of functions and requirements throughoutthe component architectures by:

● Mandate, based upon a legal or contractual com-pliance requirement

● Best practice for security, or for balance of secu-rity and business process

● Component capability, knowing the existence ofa mechanism that supports the required processor action

● Location in the configuration, based upon inter-action with components or flows

● Impact, considering the risk, security objective, orthe component capacity to perform

● Necessity, because there may be no better alter-native

Summary of the design process. This section has de-scribed the process for translating the conceptual-ized security solution into a set of detailed specifi-cations, for an integrated IT security control system,using the security subsystem construct. The designis documented, refined, and validated against the bus-iness processes through use cases and scenarios. Thedetailed security requirements, expressed in terms ofCommon Criteria component-level detail, are distrib-uted throughout the operational model for the IT so-lution. At this point, integration-level detail can be fi-nalized, and the implementation plan can proceed.

Conclusions

This paper has examined the issues and circum-stances that affect the design of comprehensive se-curity functions for computing solutions. It has out-lined a system model and a systematic process forsecurity design with the Common Criteria interna-tional standard at its foundation.

Several summary observations can be made relativeto this proposed model and process: security is ashared responsibility among all IT design disciplines;security design is linked to business objectives be-


yond the need for protecting against attack, and con-versely, protecting against attack does not in itselfmeet all the business requirements for security; andmany, if not most, security control points within ITsolutions are found in portions of solutions that arenot typically considered security components.

Reliable and correct operation of solutions using se-cure data exchange protocols, such as IPSec and se-cure sockets layer, is predicated on functions withinall five of the security subsystems defined in the pro-posed model and design process. These protocols arebased upon trusted identities that utilize crypto-

USERENROLLMENTINFORMATION

ENROLLMENTVERIFICATIONDATA

ROLES ANDRESPONSIBILITIESDATABASE

USERPUBLICKEY

USERSECRETKEY

PROOF-OF-SECRETKEY

RULES

APPROVER

AUDIT DATA

CA SIGNINGKEY

USER PUBLICKEY

CREDENTIALTEMPLATE(S)

REPOSITORY

USERCERTIFICATE

SECURITY ATTRIBUTESAND PRIVILEGES

IDENTIFYINGINFORMATION(UNIQUE)

CAPTUREENROLLMENTINFORMATION

VALIDATEENROLLMENTINFORMATION

GENERATE ANDPROTECT SECRETS

CREATE/ENABLECREDENTIAL

PUBLISHCREDENTIAL

SIGNAL CREDENTIALANOMALY EVENT

TRANSFERCREDENTIALAUDIT DATA

MANAGECREDENTIALS

ENROLL/RENEWUSER

SIGN ANDTIME-STAMPCREDENTIALAUDIT DATA

OBTAINAPPROVAL

PACKAGED CERTIFICATE

DISTRIBUTECREDENTIAL

VERIFYSECRETS

Figure 12 Sample PKI digital certificate enrollment process flow

VERIFYSECRETS

GENERATECREDENTIALAUDIT DATA

REJECTCREDENTIALREQUEST

CERTIFICATE

1234 56789 DATE

xxxxxxxxxx

John J . Smith


graphic keys requiring storage integrity, reliable keyexchange protocols, strong access control mecha-nisms, reliable data exchange protocols, and trustedaudit trails for enrollment and key life-cycle man-agement. Furthermore, the proposed model providesa new perspective for viewing Common Criteria pro-tection profiles in the context of security subsystems.For example, the protection profile for an applica-tion gateway firewall suggests the functionality of allfive security subsystems. The fact that a front-linesecurity device, such as a firewall, might fit the def-inition of a credential subsystem highlights the crit-ical nature of its design, integration, and operation.

Actions and further study

The concepts and the supporting detailed informa-tion presented in this paper were incorporated intotraining for IBM Global Services architects this year.Additional work is underway to develop notations,models, and visualization techniques that enhanceits adoption in related methods and architect disci-plines. A patent application has been filed for thesystem and process, designated Method for Archi-tecting Secure Solutions, or MASS.

Acknowledgments

This study and the project that it represents wouldnot have been possible without the leadership of ArtGilbert, who works tirelessly in building and linkingthe Security and Privacy Services methodologies intothe larger IBM Global Services community. It is trulyan honor to work with Art. Additionally, the synergybetween the concepts presented in this paper andthe tools and notations used by IBM Global Servicesarchitects is attributable to the insight and hard workof Mark Buckwell, Imran Tyabji, and Bill Blake, whoare coinstructors of the class. I would also like to thankseveral of my colleagues for their assistance, support,and understanding in this endeavor, including: Jean-Francois Ragu, Wiel Bruls, Andre Carrington, andHamid Bacha, plus the many hearty souls who par-ticipated in the review sessions and early classes.

Cited references

1. J. J. Whitmore, “Security and e-business: Is There a Prescrip-tion?” Proceedings, 21st National Information Systems Secur-ity Conference, Arlington, VA (October 6–9, 1998); availableat http://csrc.nist.gov/nissc/1998/proceedings/paperD13.pdf.

2. D. Verton, “Common Ground Sought for IT Security Re-quirements,” Computerworld 35, No. 11, 8 (March 12, 2001).

3. P. B. Checkland, Systems Thinking, Systems Practice, JohnWiley & Sons, Inc., New York (1981).

4. W. R. Cheswick and S. M. Bellovin, Firewalls and InternetSecurity: Repelling the Wily Hacker, Addison-Wesley Publish-ing Co., Reading, MA (1994).

5. RFC 1825, Security Architecture for the Internet Protocol(August 1995); available at http://www.ietf.org/rfc.html.

6. Security Architecture for Open Systems Interconnection forCCITT Applications, ITU-T Recommendation X.800/ISO7498-2 (1991). Obtainable from http://www.itu.int/itudoc/itu-t/rec/x/x500up/x800.html.

7. Information Technology—Security Techniques—EvaluationCriteria for IT Security—Part 1: Introduction and GeneralModel, ISO/IEC 15408-1 (1999); available from http://isotc.iso.ch/livelink/livelink/fetch/2000/2489/lttf_Home/PubliclyAvailableStandards.htm.

8. Information Technology—Security Techniques—EvaluationCriteria for IT Security—Part 2: Security Functional Require-ments, ISO/IEC 15408-2 (1999).

9. Information Technology—Security Techniques—EvaluationCriteria for IT Security—Part 3: Security Assurance Require-ments, ISO/IEC 15408-3 (1999).

10. See http://www.commoncriteria.org/protection_profiles/pp.html.

11. Guide for Development of Protection Profiles and SecurityTargets, ISO/IEC PDTR 15446, available at http://csrc.nist.gov/cc/t4/wg3/27n2449.pdf, pp. 69–74.

12. E. Rechtin, Systems Architecting: Creating and Building Com-plex Systems, Prentice Hall, New York (1991).

13. Committee on Information Systems Trustworthiness, Na-tional Research Council, Trust in Cyberspace, National Acad-emy Press, Washington, DC (1999).

14. A. Patel and S. O. Ciardhuain, “The Impact of Forensic Com-puting on Telecommunications,” IEEE Communications Mag-azine 38, No. 11, 64–67 (November 2000).

15. Digital Signature Guidelines, American Bar Association (1996),Section 1.35, available from http://www.abanet.org/scitech/ec/isc/dsgfree.html.

16. F. B. Schneider, “Enforceable Security Policies,” ACM Trans-actions on Information and System Security 3, No. 1, 30–50(February 2000).

17. P. T. L. Lloyd and G. M. Galambos, “Technical ReferenceArchitectures,” IBM Systems Journal 38, No. 1, 51–75 (1999).

18. H. Johner, S. Fujiwara, A. S. Yeung, A. Stephanou, andJ. Whitmore, Deploying a Public Key Infrastructure, RedbookSG24-5512-00, IBM Corporation, http://www.redbooks.ibm.com.

General references

S. McClure, J. Scambray, and G. Kurtz, Hacking Exposed: Net-work Security Secrets & Solutions, McGraw-Hill Publishing Com-pany, Maidenhead, Berkshire (1999).

RFC 2316, Report of the IAB Security Architecture Workshop(April 1998); available at http://www.ietf.org/rfc.html.

Accepted for publication May 25, 2001.

James J. Whitmore IBM Corporation, 5267 East Simpson FerryRoad, Mechanicsburg, Pennsylvania 17055 (electronic mail:[email protected]). Mr. Whitmore is currently a senior con-sulting IT architect within the IBM Global Services Security andPrivacy competency segment. His professional career includes 17years in networking and information systems security at IBM,along with prior IT experience in the electric utility industry and


the U.S. government. He holds an M.S. degree in telecommu-nications management and a B.S. degree in electrical engineer-ing, both from the University of Maryland. Mr. Whitmore is amember of both IEEE and the ACM.


a method for designing secure solutions - semantic scholar · 2015-07-28 · a method for designing...

Documents