Information Security Management Handbook, Sixth Edition (2012)

DOMAIN 4: APPLICATION DEVELOPMENT SECURITY

System Development Controls

Chapter 16. Design of Information Security for Large System Development Projects

James C. Murphy

Information security professionals (ISPs) provide a number of services within their organizations to employ. Certified ISPs are expected to be engaged in all the domains of the Security Common Body of Knowledge (CBK) (Table 16.1), demonstrating active expertise in a few and broad knowledge in the remainder. Some ISPs are more traditional—documenting policies and procedures, training users, implementing access control technologies, tracking network activities, or reviewing system logs for problems. Additionally, some provide expertise in resolving internal information security incidents or conducting recovery tasks in the event of serious interruptions to organizational services. It is rare that an ISP will have the opportunity to initiate the security planning process in an organization; e.g., in the case of a new, startup organization. Most enter into an existing information security structure and adapt to the processes, offering modifications as circumstances demand.

A large system development project (LSDP) can provide an opportunity to engage in information security planning that will stretch across all the CBK domains and will require more than a broad knowledge of each. It is an opportunity that every ISP should jump to—at least once!

This chapter offers perspectives based on my own personal experience with such LSDPs. Through the different projects, I learned some of the most important perspectives through my mistakes and incorrect assumptions, and it is those experiences that offer the most fruitful lessons. This type of experience certainly is a way to influence the design of an enterprise security structure, depending on the size and scope of the effort.

This chapter is written specifically for ISPs who face the challenge of contributing to an LSDP and will be responsible (individually or within a group of ISPs) for designing the information security structure. It can also benefit non-ISP participants of such a project, the senior Project Management staff who will oversee the project, and the subject matter experts (SMEs) who will be developing the business rules and tracking the design and development of the specific systems within the project. ISPs who are not in such a project can benefit also from the emphasis on building up the personal information security knowledge base toward the development of an enterprise security structure—end-to-end—as well as the object lessons in personal and professional communications. This chapter will not be a duplication of the chapters on application system security, found elsewhere. The efforts described here require a thorough understanding of application security but the emphasis here will be on designing and implementing an enterprise security structure surrounding a major system design and development effort.

“LSDP” Definition

Table 16.1 (ISC)² Ten Domains of CISSP CBK

The first point of clarification is the definition of an LSDP. Though each project is distinct, most have more than one of the following characteristics:

Significant organizational changes
The organization is replacing older systems or initiating major process automation efforts; the project could be a consequence of recent mergers or acquisitions, or the organization is expanding into new service or product lines.

Involves more than one organizational unit
A large sector of the organization, potentially involving a geographic distribution of units, e.g., all of “Research” or “Marketing”; or a significant change in an organizationwide service, e.g., personnel, finance, or purchasing systems

Multiyear time frame
At least 1 year and potentially, 3 or more years

External developer
Based on the lack of internal resources, it may be more cost-efficient to engage an external vendor with a similar existing system or with experience in the integration of appropriate commercial off-the-shelf (COTS) systems. In the largest of these projects, the vendor will likely propose a fiscal agent service beyond the design and development efforts. In this, the vendor will actually run the developed system and provide the emanating services on behalf of the primary organization. The fiscal agency effort will be for a contracted period of time and often within the vendor-owned data center and network.

Procurement process
Given the size and need for external help, a formal procurement process may be needed, involving a request for proposal (RFP) creation and subsequent vendor evaluation and selection. In-house developed systems will benefit from a structured planning, design, and implementation, even if a formal procurement process is unnecessary.

Any development effort that requires most of these characteristics will obviously incur significant cost, which most definitely mandates a properly managed structure. The more complex and time-consuming the project is, the more rigorous the information security planning needs to be. Even smaller projects demand a high level of security, and much of what is identified in this chapter can be scaled to fit smaller efforts. Even in-house developed projects should be expected to conform to appropriate security expectations and will require similar review and validation efforts to external vendor-based projects.

Project within a Project

The first perspective is that someone else within the organization is driving the project—usually a senior management–level group, including SMEs who are actually the focal points of the design and will judge the overall success of the project. Many of these participants are information technology (IT) professionals in their own right, with project management, programming, network, system architecture, or other IT skills. ISPs who participate are part of the team and how important a part and how much value can be added will depend on the individual (or group) of ISPs. As I will illustrate, collaboration cooperation skills will affect the value added to the project by the ISP. The security perspective will essentially be a project that is threaded through the larger project, potentially affecting all systems and subsystems, especially the data and information components of the subsystems. This perspective will be driven by regulatory responsibilities (pertinent to the organizational posture) and will be integral to the architecture designs for both software and infrastructure. ISPs will help ensure that access to the data and information is restricted appropriately and that the data and information are protected even during and after major disasters and other service interruptions.

Project Management Structure

Most large projects will be structured in a logical way to provide context and to help facilitate the implementation, and the information security perspective should have a similar structure. For this chapter, I will use the Deming cycle (Figure 16.1). (http://www.balancedscorecard.org/TheDemingCycle/tabid/112/Default.aspx), which offers a familiar perspective to project managers. It also speaks to the continuous nature of information security management and helps indicate the reality that the protection of the information and services succeeds the actual project itself—once the project is formally accepted, the information security management actually elevates to a higher and more persistent effort.

Figure 16.1 The Deming cycle.

The next section is Before the Beginning, which highlights in some detail the need for preparation in all areas of information security, including a clear understanding of key information security terms. Vital to the success of all phases of the project are the personal communications skills of the ISPs—knowing the subject matter, knowing how to listen at all levels of the organization, and knowing how to provide answers in appropriate settings. This will be the largest section of the chapter, reflecting the importance of laying a solid foundation before the project actually starts. The remaining sections reflect the components of the Deming cycle.

Throughout the LDSP, the ISPs will PLAN for the components and requirements of security demanded by the project design and expectations and based on the organizational characterization. This will lead to the development of a Security Specification that documents the expectations for the finished system. The ISPs will DO the next part by designing the information security requirements and reviewing the selected vendor’s responses and assertions to the requirements. Then, the ISPs will CHECK by participating in testing the system as designed and assessing the fulfillment of the security assertions made during the design and development. Finally, during the Preoperations and actual operations, the ISPs will ACT to ensure that all the security components are indeed in place and are tracked and assessed appropriately, both at the completion of the project and through the subsequent challenges.

Before the Beginning

A participant in any major project requires significant depth of domain knowledge appropriate to their role within the project. This is especially the case for ISPs involved in an LSDP. In this case, ISP participants must have a broad, practical information security background knowledge to a significant depth within all 10 of the CBK domains—certifications are certainly preferred, but actual experience across the range of the CBK domains is vital. This should include a familiarization with the state of Information Security Warfare—the general picture of attacker patterns. Experienced ISPs should have a healthy and growing sense of paranoia! Knowledge of the organizational industry sector enables an orientation of the security knowledge toward the specific types of industry- and organizational-specific data and information at issue with the impending LSDP; which will also help identify the potential attacker targets. Industry sector knowledge also identifies the general and specific regulatory environment that underpins the governance structure for the organizational information and data.

Knowledge and expertise are the baseline, but it is not sufficient for a successful involvement. Most of the project participants will have a general understanding of information security, and the terms involved, but most will not have the same grasp of information security as a well-experienced ISP. This discrepancy in the understanding of information security details has the potential for causing the most difficulty in planning and implementing a security plan for an LSDP. The burden for avoiding the consequences of conflicting terms and definitions falls squarely on the ISPs involved! The most significant mistake for an ISP is to assume that all other project team members understand information security terms and frames of reference exactly as she or he does.

A example of an apparent lack of communication between ISPs and other IT professionals was illustrated by Chris Murphy (no relation!) in a recent Information Week article. In the article, Murphy interviews several chief information officers (CIOs) and other IT professionals about general impatience with the slow pace of IT projects (e.g., LSDPs!). In one section, information security was at issue, and Murphy quoted a consultant and former CISO.

… security and regulatory compliance make business IT more complicated than consumer IT, but security can’t be the overriding excuse for not moving faster.

CISOs must bring more of a business point of view to their security judgments… . CISOs must weigh a delay against the risk and decide if the app can be rolled out and any problems resolved along the way. Again, it’s velocity over perfection—and it’s heresy to some security pros. “CISOs need to get comfortable with that, [the consultant] says.”

CISOs also need to … [automate] more security testing … . “Reserve these really good security people for the really difficult security problems [the consultant] says. … Too often, the interpretation of a law or regulation gets debated anew with every security problem.”

This offers an example of a professional difference of opinion about the importance of information security within a project development effort. The consultant appears to express an opinion that IT security is a troublesome task that needs to stay below the radar of project or system development. It also highlights the need for careful planning and personal/professional communication about the various aspects of information security within the development process.

My own personal experience when I began with an earlier project reflects this. I spoke readily to other project participants about information security terms, concepts, and regulations, but I found that I was not being heard, or I encountered disagreement about information security practices and concepts. I was clearly not communicating past the apparent barriers! After more discussion and consideration, it became clear to me that I was the problem and the reason for the barriers! My communications skills were at issue, and after reflection, I wrote and published a paper that described my situation (Murphy, 2009). Much of the following paragraphs are drawn from that paper, with some updates from the years since it was written.

As the title of my paper indicates, I was frustrated that “no one was listening,” but I did finally comprehend my responsibility:

“The very security professionals who are convinced that we have the answers are the primary barriers preventing the message from being heard.” (Murphy, 2009)

There are three personal/professional areas that need attention for ISPs to communicate effectively:

Know the message

Win the right to be heard

Be always ready to give an answer

Know the Message

Knowing the message includes the knowledge gained from experience and/or certification. It also involves understanding crucial information security concepts and how they are interpreted and used within the context of the impending project. As mentioned above, nearly everyone in the organization connected with the project will have an opinion on specific information security terms and frames of reference. Four specific terms are at issue:

Trust–Privacy–Security–Risk

These are key terms for all ISPs, and yet these represent most of the significant differences of opinion among all types of IT professionals. As a matter of learned practice, I offer my own contextual definitions of these terms, acknowledging that differences may exist. Yet, I intend to be clear about how I use these terms in explaining the breadth of enterprise security.

Trust is a concept that I believe has been overused. It is prevalently used in most current literature describing potential networking relationships and in many recent privacy and security standards documents. Examples are such as: “… we need to establish trust among …,” “… [the effort] builds trust that is essential …,” “… this constitutes a trust agreement … .”

Its persistent usage is understandable and it speaks to a genuine desire for positive human relationships, but I believe it no longer reflects the reality of our twenty-first century societies. The option for “trusted hosts” within UNIX environments was eliminated more than 20 years ago when UNIX became a mainstream operating system. I believe we err in designing legal documents that assert “trust” among the signees. I do believe it is possible to develop reliable trust among close friends and family (with exceptions!), but I believe that it is increasingly impossible to develop trust among large groups, such as one organization to several others where data and information are expected to be shared.

The following limited set of recent articles speak to the problem of “trust,” as reflected in the titles themselves (Table 16.2):

Table 16.2 Recent Articles on Trust

The last article describes the awful invasion of privacy by the employees of the medical center treating the tragic victims of the January 2011 shooting in Tucson, Arizona.

“Trust” agreements signed by the officials of the organizations do not actually provide trust or guarantee any assurance of trust; they only establish the application of consequences of the breach of the contract. The reality of the twenty-first century is that though we talk about “trust relationships,” in reality we actually do not trust—groups or individuals! There are too many loose ends—within our own organization (we cannot absolutely control the behavior of all workforce members) and certainly within the remote organizations. Also, it should be apparent to all (certainly to ISPs) that the Internet is becoming increasingly hazardous to the integrity of all transmitted information (and to the health and wealth of the owners of the information). That is clearly indicated by the technical and physical barriers we place between the outside world and our information! Agreement documents are vital, because they do provide clear consequences for breaches; however, I strongly suggest that they be described as Data Protection Commitments indicating each party’s role in exchanging and protecting the other’s information. Finally, any agreement requires disciplined follow-up, by means of active infrastructure monitoring, service assessments, and process audits to prevent or rapidly detect any possible interruptions.

In the last 10 years, the debates over Privacy and Security have increased and become more polarized in the aftermath of several national and regional crises. Most of the debates address the apparent dichotomy (or tug-of-war) between the two concepts. The quantity of publications is overwhelming as the need for personal privacy is measured against the importance of societal security (e.g., Rotenberg, 2007; Sanchez, 2009). The debate is over the importance of choosing one concept over the other or how to balance the importance of each. The debate is often characterized (sensationally) as a choice between a Police State monitoring every individual’s activities and the imminent invasion by foreign forces. Ironically, both sides of the argument describe the “worst case scenario” as the disastrous loss of personal liberty on a grand scale! Schneier (2008) rightly sees that there is (or should not be) a dichotomy, because security (at least technical or informational) can be implemented without a complete loss of privacy.

This predominant view of privacy has a human-personal characterization—identified by phrases such as “my space,” “my personal identity,” or “my health record.” This is the perspective of most legal and compliance efforts in organizations, epitomized by the recent healthcare regulations. In this context, privacy is often stated in terms of personal control, and recent updates to healthcare regulations (HITECH Breach Notification Interim Final Rule, 2009) have been implemented to strengthen the enforcement of the original regulations (Summary of the HIPAA Privacy Rule, 2003).

In the context of protecting data and information, I target a different characterization of privacy and security that more appropriately suits the LSDP at hand. This view is from the perspective of data and information, and as such, privacy refers to specific categories of digitized or paper information identified or classified as private/personal about identifiable persons. For ISPs working on the large project “privacy” refers to information that others in the organization have identified and specifically classified as “private.” It is a subset of the larger body of corporate information, but not necessarily the only private information. Other subsets of organizational information may be designated as “private” or “proprietary” as well for different reasons. This “private” information, then, is the appropriate target for protection mechanisms.

In the debate referenced above, security also has a personal context, indicating protection of human life and liberty from forces intent to harm. Information security, as distinct from personal, human security, is the totality of policy, technology, and process efforts implemented to protect private data. From an information management perspective, both privacy (the characterization of selected information as “private”) and information security are necessary—privacy cannot be assured without adequate information security, and information security cannot be efficiently implemented without the identification and classification of private information. To be clear, privacy and information security are distinct (not synonymous) and they are complementary—both disciplines are necessary for a complete protection scheme. Information security is not simply a privacy requirement (established by regulations and compliance standards), but it enables privacy requirements to be fulfilled.

The confusion of information security with privacy is not the only problem. ISPs struggle with a general lack of appreciation among organizational workforce members for the breadth and depth of information security. To be clear, information security is not (exclusively):

A product

A checklist

A regulation

A headcount

A budget item

An IT problem

Information security certainly encompasses all these ideas and items, but it is more clearly defined as:

an organizational initiative that requires the responsible participation of all workforce members—top to bottom!!

Information security has often been correctly characterized as a process, but it will be most understood and appreciated when it becomes an organizational culture among all the workforce, and an ongoing discipline among the ISPs and other IT staff in monitoring points of vulnerability.

The simplest description of information security is that it performs two main services: providing protection of and controlling access to data and information. The “CIA Triad”—Confidentiality, Availability, and Integrity—have been recognized as attributes of information security (Perrin, 2008) and have brought needed recognition to the discipline. In reality, they reflect the qualities of data and information and they are misused when seen as measurable values, as such, they provide an incomplete picture of information security.

Table 16.3 indicates more of a complete, contextual description of information security, under the two main services. These characteristics include qualities of data and information and practices involved in the two main services. Continuity and Encryption are emphasized to indicate that there are components of each that help protect and control access to information.

Identity management includes authentication, the matching for the sake of the system of personal identifiers (user ID and password) to an individual person; authorization, first, the granting of permission for accessing selected system components (from a data owner or manager), and second, the enabling of the permission within the architecture of the system; and provisioning, the practice of activating modifying, monitoring, and deactivating the user accounts established by authentication and authorization. These three activities, authentication, authorization, and provisioning, make up the larger service process of access control. Note that the combination of the user identifier and the password is considered single-factor authentication. Adding more identifiers (e.g., a pin number and/or a biometric marker) creates two- or three-factor authentication.

Table 16.3 Information Security in Context

Information security will not be complete by simple initiation of the contextual characteristics. All efforts require processes to be defined and documented, and all the components require the disciplines of organizational workforce training, active monitoring, and periodic auditing for consistency and continuity of practices.

Finally, Risk is the last of the four information security topics that requires attention. In a previous writing (Murphy, 2011), I detailed my views on the muddled picture of risk and expressed the need for clarification, especially within the context of information security. Risk management is a top-down, Senior Management–led endeavor with collaboration from several organizational groups. ISPs contribute to the complete picture by assessing the vulnerabilities. The first column of Table 16.4 indicates the classic, general view of risks, summarized as the probability of monetary loss. IT risks (middle column of Table 16.4) are the specific types of threats and vulnerabilities involving information, which include additional monetary consequences due to fines, penalties, and lost reputation. The third column emphasizes the actual contribution of ISPs to risk evaluation—controlling information vulnerabilities, which include proper care and management of infrastructures, careful management of software environments, and appropriate documentation and communication for organizational workforce members.

Win the Right to Be Heard

Information security is a service provided to the larger organization. ISPs certainly have more information security knowledge and experience than most of the organizational workforce, but sometimes that knowledge is a barrier to effective communication. As the LSDP efforts begin to pick up steam, ISPs will have more chances to interact with other workforce members. Regardless of the size of the ISP group (one or many) or responsibility within the group (e.g., manager to entry level; technical or policy writing; help desk, etc.), all ISPs will have interactions with the rest of the workforce, whether in formal training classes, organizational committees and teams, or even hallway conversations.

Table 16.4 Risk Perspectives

In every circumstance and opportunity, the most important communication skill for ISPs is LISTENING!! In casual hallway conversations, one can “pick up” information about the background and planning for the LSDP—often more can be learned than from formal meetings and presentations! As the project begins to form, ISPs will have opportunities to meet more formally with data owners, from whom descriptions of the current state and the reasons for the change, and ultimately, the access restrictions from specific subsections of the future system (listen). Additionally, meetings with SMEs will provide more details about the business processes and types of data that will be needed (LISTEN). Formal presentations by senior project and business management will indicate the initiatives, plans, and goals of the future system (LISTEN!). All these opportunities will provide a foundational understanding of the future system, and the ISP can begin to identify aspects of the future system that will require information security attention.

From these listening opportunities, the ISP can begin to fit into the organizational jargon and hopefully, can begin to be accepted as an “insider.” During this time, before the actual procurement process for the LSDP begins, the ISP can build knowledge about the organization itself and the overall picture of the merits and justification of seeking the future system. Table 16.5 summarizes the types of valuable context information that will assist the ISP in crafting appropriate information security plans for the future system.

Table 16.5 Organization Characteristics, Targets, Needs

Be Always Ready to Give an Answer

Targeted listening is the key that opens up the sources of information that will be vital for the ISP to build a set of plans for the future system. As may be expected, as the anticipated project begins to come together, careful listening will lead to questioning, and questions will require appropriate answers. Based on the knowledge and experience with information security, and the context of the organization’s current state and future plans, ISPs must be ready to respond. Responses should reflect the nature of the question asked in the specific organizational context, not the overall general knowledge of information security. ISPs must be ready to respond to informal questions that may come within the hallway conversations as they pertain to the impending project. Other questions may come from help desk calls, e-mail requests, or job-related problem solving. Admitting ignorance to selected questions is not wrong, especially when accompanied by an expressed interest in researching an answer. Questions may also arise in meetings based on targeted discussions, and again, contextual answers with commitments to research will help the ISP gain the confidence of the questioners.

ISPs may be asked to make formal presentations in some of the meetings or in more targeted planning sessions. These could also be based on specific information security topics or technologies and may allow time for research and preparation. Beyond those, ISPs may offer written communications on targeted subjects to address certain aspects of the future system. These writings may be delivered in newsletters or blogs, specific “white paper” essays, or formal journal publications.

ISPs must be able to blend the listening to the felt needs of the organization, and the understanding of the current state and future system contexts toward the preparation of general and specific responses. The ideal result will be the growing sense of confidence, expressed by individuals within the organization, in the ISP as a competent, if not important resource for information security within the planning and implementation of the future system.

The following list is a set of actual questions or topics that could be posed by the other participants during various discussions or meetings leading to the planning of the future system. ISPs can consider these as a starting point for understanding how to prepare and present information security topics in organizational context. Obviously, many more similar topical questions could be posed, the most important consideration is to keep the answers in context.

Professional Responses

Can you recommend standard methods and practices for developing secure software within small or large system development projects?

Can you break your overall plan into incremental steps that will better fit a budget-managed environment?

Can you identify and present the return on investment (ROI) that information security enhancements can bring to the organization?

Have you read (or at least identified) the international, national, and local laws and standards about information privacy and security that directly affect your organization’s practices?

Can you participate in organizational discussions about the distribution of responsibilities for personal safety and information security practices?

Do you know how to answer the questions about incidents that may lead to emergency response or disaster declaration within your organization?

Will you be able to answer the questions about liability of data loss within your organization?

Will you be able to initiate (or participate responsibly in) an investigation of data loss or theft?

Can you give answers to the questions about numbers and types of successful and unsuccessful attacks on your network?

Can you recommend technology solutions and countermeasures to prevent such activities in the future?

Can you recommend business practices and behaviors that will also mitigate the same activities in the future?

Can you design and lead a security assessment after the project is complete and the system is in production?

PLAN–Do–Check–Act

Based on the communication efforts described above, the ISP now has a foundation for planning the information security portion of the future system. Before the LSDP is formally initiated by organizational management, teams will be formed and documentation about the future system will be accumulated. The ISP will be a participant in the larger project and will follow the planning structure, project sequence, and general direction of the Senior Project Managers. ISPs will certainly work closely with the IT technical staff contributing to the design of the infrastructure, architecture, and network environments. The main task for the ISP at this stage is to draw on the organizational understanding gained, fill in missing pieces from deliberate interviews and meetings, and produce a general Information Security Specification that will describe the overall information security structure of the future system. We will assume that this future system will indeed be designed, developed, and administered by the vendor as a fiscal agent and housed at the vendor-owned offices and data center. This means that the specification will address the complete enterprise security of the system, its workforce members, and its technical and physical support structures. Trained and experienced ISPs are able to define a generalized enterprise security structure, but the challenge here will be to tailor the specification to the organizational specificities.

Before diving into the preparation of the security specification, there are a number of foundational perspectives for ISPs to keep in mind. First, remember that information security ….

Provides Protection of and Controls Access to Data and Information

For the duration of the project—planning, procurement, design, development, testing, preoperations, operations, and beyond—remember these guidelines about managing information security:

The Most Important Information Security Asset:
The Human Resource (internal)

The Greatest Source of Threats and Vulnerabilities:
The Human Resource (internal and external)

The Most Important (and Most Difficult) Context:
People > Information > Technology > Process

The Most Important Capability:
Personal Communication (all kinds)

Information security is fundamentally about influencing people!!

From the background and familiarization gained (above), the ISP should be able to document the organizational posture:

Size, growth (expansion, mergers/acquisitions)

Public or private status (there are many important differences)

Industry sector (partners, customers, competitors)

Regulatory and standards environment (much more rigorous with public sector organizations)

Nature of the future system (replacing a legacy environment or entirely new)

Senior executives, project managers, and SMEs will be the greatest official sources of these circumstances and characterizations. The SMEs and the organizational users who will employ the future system will be identifying and documenting the overall business purposes, including (ideally) the business rules that describe the desired work functions addressed and served by the future system. The system will have an overarching purpose and will be composed of subsystems that define the components and collateral systems. The SMEs and primary users will define the business rules—activities described in plain language—that comprise the subsystems. The breadth and completeness of the sets of business rules will facilitate the design and development of the overall system.

ISPs will need to attend to the subtending data and information which the subsystems will use and/or generate, especially if it is sets of private, protected (by regulation) information about identifiable people. From the start, it is important to identify the sets of private information and the expectations of its protection by the users and SMEs. Even though other technical groups will handle the transfer of data from the legacy environments (if any), including conversion from the old to the new environments, ISPs will need to confirm that private data is protected during transfers and that older copies (if any) involved in the transfer are destroyed after the transfer and conversion.

The SMEs and system users will determine the ultimate inputs and outputs of data (included private and/or financial information) and will be the primary resource for estimating the volume of information and its growth over time. The outputs may be products of specific services of the future system and may include custom searches and regulatory reports for external databases. The SMEs and users will be the decision makers for the access restrictions to various sets of data within the subsystems, for the most part defined by regulatory requirements. They will also determine (drawing perhaps from regulatory requirements) the nature of the stored data and information—online, near-line, backed up, archived, and the lengths of time for each type of storage. ISPs will be expected to be familiar with all regulations affecting the sets of data for the new system and will ensure that any regulated audit and reporting requirements are documented as part of the overall requirements development.

From the preceding details derived from the SMEs and primary users of the future system, the ISP can begin to draft the security specification that addresses the uniqueness of the future system and its environment. The specification should be written as descriptive text, for a general nontechnical audience at a sufficient length to address the overall scope, ideally 5–10 pages. It should express the specifics of the information security expectations, not in exhaustive details. The specification will be the basis for the security requirements within the formal RFP, but it will not necessarily be part of the RFP. The specification should be structured in a way that enables the project team to grasp readily the required security environment. I recommend that the most effective way is to create a document framework that indicates the auditability of the overall system, once completed. An audit framework will be recognizable by senior management and project management participants—not to mention internal auditors—and will facilitate communication about the security expectations.

Several audit standards offer frameworks that should be familiar to business-oriented users and to ISPs as well. I recommend using the Federal Information System Controls Audit Manual (FISCAM) (U.S. GAO, 2009), which offers a straightforward categorization of enterprise security general controls, as summarized in Table 16.6. The intent for using the FISCAM structure is not to duplicate the detailed control schemes within the FISCAM document itself, but to describe in brief statements the expected security structure within the future system organized with the FISCAM outline. The Security Specification can be used to convey the details of the expected security structure in discussions or presentations with the rest of the organizational project planning group as an internal working document. It can certainly be modified based on comments and feedback as the project begins to unfold. Take advice of the senior project managers about offering the Security Specification to the vendors who will bid on the system. It may not be appropriate because vendors may attempt to bid the Specification itself, instead of offering their own interpretation of the requirements.

Table 16.6 FISCAM: General Controls

Plan–DO–Check–Act

At this point, the actual work begins. Under the leadership of the senior project managers, the ISPs will participate in all the phases of the project. Table 16.7 indicates a high-level view of the major phases, but note that this list is idealized and may not reflect all types of LSDP phases.

Procurement Participation

The descriptions below are not meant to be a complete, detailed description of the procurement process and the development of the RFP, but to offer illustrations for discussing the ISP participation. Each procurement and RFP process is unique and tailored to the subject matter and to the size of the project; the information security contribution is a subset of the greater work of the project managers and SMEs and their teams.

Table 16.7 LSDP Major Phases

ISPs (and all participants) must understand that procurement is a formal, controlled set of activities. Ideally, it will be led by senior managers with sufficient formal project management experience in managing large projects. For larger projects involving significant cost, there may be legal implications of how the procurement processes are conducted. This is even more important in public sector organizations (local, state, and federal government agencies) where competitive bid processes are required. Proposing vendors will undoubtedly be submitting proprietary information, if not technology, and each vendor will expect confidentiality in the review of the submitted proposal information. This also means that there will be restrictions on communication among the procurement participants to ensure that the proposal information is kept under wraps. Any organizational staff who have clear conflicts of interest (e.g., personal involvement with any vendor—family member employment, significant vendor investment holdings, etc.) may not be permitted to participate in the process.

Private organizations may not be tied strictly to a formal procurement process, unless competitive bidding is expected. Nonetheless, even private organizations who approach a single vendor directly will be best served to follow a formal proposal process similar to the procurement process to clarify detailed expectations and to reduce ambiguity during the creation of the system.

The general sequence of events in the procurement process will begin with the crafting of the RFP, though preliminary announcements or formal Requests of Interest may precede the RFP. In this, the desired system is described at a high level, the sequence of events are described (including calendar dates), the contract and other legal obligations and regulatory responsibilities are documented, the organization’s expectations of vendor qualifications are spelled out, the actual proposal processes are defined, and all the detailed requirements of the desired system are listed. The set of requirements will include specific subject matter subsystem requirements toward the overall purpose of the large system. It will also include general sections, spanning or supporting all the subsystems, which include system architecture, interfaces (for users and between subsystems), service level expectations, and information security. Business continuity and disaster recovery requirements may be included within the security section.

After the RFP is submitted for public review, vendors may be given an opportunity for questions and comments about the RFP, and the organization will have a similar opportunity to respond and clarify the vendor issues raised. By the announced date, all the proposing vendors are expected to have submitted a complete, authorized proposal, following the expectations of the RFP, which also may include personal interviews and/or proposed system demonstrations.

The evaluation process is next, during which all vendors whose proposals were accepted are formally reviewed and evaluated. There could be legal implications involving the details of the evaluations, which may include careful control of written notes and a ban on discussing the evaluations—with anyone in or outside the organization—outside the formal evaluation sessions. After the evaluations are completed, some procurement efforts may indeed allow the vendors to make adjustments to their proposals based on the evaluation summaries. When the evaluations are complete, a separate group, usually the project management staff, will rank the vendors and make the final selection.

During procurement, the ISPs will be able to draw on the security specification plus feedback to create the requirements for the components of information security. Requirements must be crafted to be clear, succinct, and unambiguous and organized topically to avoid duplications and inconsistencies. Ideally, all the information security requirements should be in a separate section, (arranged in sections similar to the structure of the security specification) with clear instructions stating the general applicability across all the systems and subsystems. Some security requirements may be addressed in legal/contractual sections or in architectural and systems administrative sections. The RFP will be a legal foundation for the subsequent design and development of the new system, so ISPs must ensure that the set of requirements is complete and addresses all the expectations of the security specification. The RFP will be referenced frequently during design by both the organization and the vendor to clarify differences of opinion. Adding new requirements after the process begins could be difficult and costly.

Optimally, requirements will express the expectation that the vendor will be able to accomplish the object of the requirements in the future system, e.g., “provide capability to …” or “document intent for ….” The requirements also should be objectives-based, which means that the requirement statement will briefly solicit a solution to a specific desired state, giving the vendors the opportunity to describe how they plan to fulfill the desired state. Requirements that include examples (use of “e.g.” or parenthetic suggested lists) may lead the vendor to propose exactly the examples provided, when the expectation was for something broader or more inclusive. Requirements should not be posed as questions, because that gives the vendors opportunities to respond simply with an affirmative (no vendor will ever respond with a negative answer to a requirements question!), and reduces or eliminates the expected explanation from the vendor. The intent is for the vendor to propose the final solution or the plan for the desired state in some detail. This provides the basis for evaluating the vendor responses; it allows for questions seeking clarification and more detailed explanation and for ultimately making comparisons that lead to the final selection.

Table 16.8 provides examples of the benefit of objectives-based requirements.

The first example spells out details that describe a classic backup structure using tapes and specifying timeframes and distances. This will lock the vendor into exactly fulfilling the requirement. The alternative gives the vendor the opportunity to describe what the vendor considers to be a protected backup environment, what timeframe is “prompt,” and what distance is “sufficient.” Under the alternative requirement, a vendor could propose a real-time mirroring or shadowing backup environment with an archival on disk storage arrays that uses no tapes. Recovered files could be brought back in seconds by enabling a remotely mounted backup environment directory structure. The vendor could also propose a location for the backup environment that is geographically separated from the data center but may be less than 50 miles distant.

Table 16.8 Objectives-Based Requirements

In the second example, there will certainly be other incident sources besides undesirable IP addresses, and there are also more malicious software threats than the ones listed. The suggested list could be interpreted as the only malicious software to be blocked. The alternative allows for the vendor to propose a comprehensive incident response plan that will allow for thorough evaluation and comparison with other proposals. Not every requirement will be stated with an open-ended expectation; some specifics will indeed be expected, if regulations or organizational policies and standards already spell them out in detail.

The third example attempts to address the need to establish the separation of duties or responsibilities so that no individual will gain control over the whole environment. As stated, the requirement is specific for a number of situations, but deals primarily with systems and operational staff and delimits the password change frequency, which may or may not be appropriate. It does not address the need for physical protection of the system administrator/operator environment, which is an example of an omission that may result in a future costly change request. The alternative explains the desired state and leaves it to the vendors to describe their approach in as much detail as needed.

All three alternative requirement statements emphasize the need to require documentation for the desired processes and capabilities. Hopefully, most vendors will assume the need for documentation, but such assumptions may not necessarily be reliable. A desired expectation for documentation of processes, policies, and procedures may be stated in some of the introductory sections of the RFP as a general requirement for the whole system, which would then obviate the need for repeating it within each individual requirement. For any points of confusion or concerns about requirement verbiage and expectations, it may be advisable to consult with the legal or contracts experts within the project team. For truly large and expensive LSDPs, ISPs should definitely include a requirement for an internal assessment of the security structure before the system is accepted. Many problems can be detected and avoided with a final security assessment!

The proposal evaluation will be led by the project senior management, and ISPs will be expected to address the appropriateness and satisfaction of the responses to the requirements. In general, ISPs will be determining if the vendor has an acceptable concept of enterprise security as well as responses that demonstrate awareness of current and future information practices and technologies. The open-ended, objectives-based requirements will allow for creativity on the part of the vendors and possibly different responses among several vendors. During evaluation, direct comparison between vendors will not be allowed; rather each vendor will be assessed separately. Ultimately, the comparison will be made by the senior staff who actually choose among the proposals, taking additional criteria into account such as cost, time until completion, vendor reputation, experience, and fitness for the project. In large, expensive projects, it is possible that the finalists (two or three vendors) will be allowed to make modifications to their proposals.

System Creation

Once the selection has been made for the optimal vendor, the workload of all the project participants will actually increase. All the project staff will be reviewing the initial set of documentation from the vendor based on the final proposal. The vendor is expected to document the detailed design of the various subsystems for the larger project, as well as the general areas including architecture, information security, and business continuity. Depending upon the size of the project, other general documents may be separated out, such as risk management, change management, network design, identity management, and others, as appropriate. All the project staff are expected to review and critique the design documents for matching and fulfilling the requirements and for the detailed description of how the operational systems and subsystems will work and interoperate.

ISPs will be reviewing the technical documents for descriptions of information security practices and processes for the future production environment. In these cases, ISPs will be working closely with the other IT technical participants, including the server-network architecture professionals as well as the software development professionals. The process will include tracking the requirements from the RFP through final proposal and in the design documentation. The design documents will contain assertions about the future state of the system. As the project unfolds, the ISPs will be responsible for tracking the assertions through the development and into testing and production to validate the assertions—finding the evidence and documentation to ensure that the vendor actually performed as asserted.

Besides the requirements tracking, the ISPs will have the responsibility for tracking any vulnerabilities that may be evident in the design of the systems and subsystems. This is where an understanding of software development security becomes important. Most of the SMEs will be reviewing and critiquing the design documents for functional requirements. ISPs are expected to assist the software development professionals in insisting on requirements that capture most of the software vulnerabilities before the designs are implemented. ISPs can also scan the design documentation for data flow patterns—how data is brought into the subsystems and then disseminated to others through various interfaces, within the larger system and to external systems beyond the organization. These design documents will also describe storage and archival processes and will include access permissions and restrictions. ISPs will be able to review these processes, looking for omitted, incomplete, or inadequate descriptions and inconsistencies in descriptions of the same process across multiple design documents. Ideally, problem areas can be caught in the review of the documentation, and corrections or controls can be offered by the vendor. All identified vulnerabilities in the design documents should be documented, along with the specified control(s); the vulnerabilities document can be part of the preoperations security assessment to ensure that the controls recommended are indeed implemented.

It is becoming very rare to see a software development initiative that does not employ a Web interface for user interaction and electronic commerce. ISPs and software development professionals are expected to be aware of this explosion in usage of Web tools and interfaces and the extreme vulnerabilities that exist in Web development design tools. All participants, therefore, should be familiar with the advancements in developing secure interfaces that will afford protection from many of the Internet threats, indicated by the links in Table 16.9, which provide a wide range of resources for ensuring a high level of security within Web interface development. The RFP requirements should expect that vendors have a working knowledge of the standards and processes so described.

It is important to complete a thorough review of all design documentation during the allotted time. Once the documents are reviewed and corrections are made, the documentation is ready for finalization and authorized acceptance. Any problems discovered in the documents after acceptance of the final versions will require an unplanned expense.

The general documentation, e.g., security, business continuity, architecture, change management, risk management, will be subject to the same review and requirements tracking. Because they are describing a future state, it will be appropriate to consider the initial set of documents as “preliminary.” It will be expected that these documents will undergo at least minor modifications as the complete system is finalized. The “preliminary” plans will be finalized during the preoperations stage and will also be subject for review. These final documents should contain no assertions for planned processes and technologies, but clear descriptions of the final states. The final versions of these general documents will be the bases for live operations policies and procedures.

Table 16.9 Resources for High-Level Security in Web Interface Development

Plan–Do–Check–Act

After development of the system, logically comes the testing. In general, there are two primary test categories involving the created system: systems (or systems integration) testing and user acceptance testing.

Typically, systems testing is performed by the vendor to check the functionality of the initial coding and to ensure that the developed systems and subsystems integrate appropriately. On some occasions, users may participate or at least observe this testing process. All such tests and results are expected to be made available to the organization for review and explanation. The tests may also be staggered, depending upon the completion timetables of the subsystems. ISPs need to be aware of any problems where data leakage may occur during interchanges, and if the logging mechanisms capture problems appropriately, but most of the review will be handled by the project managers and the SMEs. These reviewers must be able to accept that the system is performing as required.

User acceptance testing does involve active participation by the project team members and possibly organizational users outside of the project team. This level of testing should address business processes and work flow requirements as required, and the vendor should be able to demonstrate the expected performance of the system. This testing should stimulate the production system, but with the expectation of finding (and correcting) problems. Vendors should be challenged to complete the development sufficiently for performance evaluation, eliminating as many problems and bugs as possible, and not to employ user testing as a shortcut to the final development. ISPs will be more involved in this level, because potentially, live data from a legacy environment may need to be transferred. If any data is private or regulated, then the exchange must be protected and documented. Any media used in transferring the data must be destroyed appropriately and with proper authorization. The user testers will also look for correctness of interface transfers, including matching record counts, and where financial transfers are involved, the totals must also balance. Also, ISPs will be able to track problems within the logging mechanisms of exchanges and errors, accidental or deliberate.

Apart from testing the systems themselves, ISPs will also need to be involved with testing of the user interface (especially for a Web interface) and the mechanisms behind user authentication and authorization. More than likely, the details of the design of the user access control environment will be documented in the security plan. ISPs should be able to review the provisioning plans and observe sufficient demonstrations to evaluate the effectiveness of providing access only to authorized users. The processes should be according to the requirements, and most importantly, a deprovisioning process should be described and demonstrated. Part of the testing should also include attempting to break in with a known unauthorized user ID and password and observe the system response and the access log files for evidence of the rejection. The vendor technical staff also will be expected to describe the long-term monitoring and assessment practices of the provisioning efforts.

Other tests may be necessary, depending on the nature of the system being developed. If legacy system data is expected to be transferred to the new system, it will most likely require conversion testing. This requires careful planning to ensure that the records transferred will be acceptable and may involve the processes of extraction, transformation, and loading (ETL). Extraction is the collecting of the data from the older system in an ordered manner, which may involve an authorized transfer for private, regulated data. Transformation aligns the older data terminology and record structure to the new system structures. This can be complex and time-consuming if the legacy system is much older than the new replacement system. Finally, Loading is the careful moving of the transformed data to the new system records. ISPs may be involved in planning and observing, but this process is usually driven by the SMEs and project management staff.

If the new system is to be hosted and managed by the vendor, a series of network assessments will be required. Ideally, an external service organization will be contracted to provide network discovery, penetration tests, common vulnerability assessments, and perhaps Web interface evaluation. ISPs will be involved in planning, but the validity of the effort depends on the work being performed by a truly independent organization.

The primary testing responsibility for the ISPs will be the preoperations security assessment. This is most important for any system that involves collecting, storing, and processing regulated data and information. The assessment can be based on any standard security review or audit methodology, as long as all areas are examined. It is not expected to take the place of a postoperations assessment or audit (depending on regulatory requirements). This assessment will best be performed as an advocacy process, where the organization and the contracted vendor participate together in a collaborative effort. The objective is to achieve a clean, secure environment, not to embarrass or find fault with the vendor. It should be led by the ISPs and should include the vendor ISPs and other organizational representatives as recommended by the senior management. The assessment should include specifically reviewing the vulnerabilities identified in the design and development phases, looking for hard evidence that the controls have indeed been implemented. The bulk of the assessment should track all the assertions and intentions to their final implementation, which may be the operations manual and final versions of the security and the business continuity plans. The summary report should include “findings” that will certainly need prompt attention as well as references to existing documentation for all the enterprise security structures. The assessment can also provide a preparation of documentation and other evidence that may be useful in any future postoperations audit. The assessment may also include a review or table-top exercise of the business continuity plan, although this may be a separate plan altogether. If possible, and if warranted by the nature of the new system, it may be desirable to observe the vendor’s formal business continuity recovery test.

Plan–Do–Check–ACT

Finally, with the new system loaded and tested, and with the vendor staffing underway, the whole environment is ready for the initiation of formal operations. Arguably, this may be counted in the previous section (“Check”), but because all of the formal testing is complete, the environment is expected to be in final operations status. Before the contract is finally settled, the environment will undergo an operational readiness review.

This may be the opportunity for running the new system in parallel with the older system; attempting to run the same processes with the same data on both environments. Because the two may be significantly different in architecture, infrastructure, and software, a truly parallel test may not be possible, but the exercise will allow for valid comparisons. In all practicality, the older system should not be taken down before such an exercise has been conducted. This may also be the time that all the latest data from the legacy system—since the earlier tests were conducted—will be moved to the new environment. This again may require a controlled, authorized process to protect regulated data and information. This also may be the best time for simulated stress testing to ensure that volumes of data and numbers of processes can be achieved as required and expected. This is also the opportune time for training of the organization’s general user population as well as the vendor staff who will operate the live system.

The final efforts before formally initiating the production environment involve signing off on the major achievements. These sign-offs may not characterize all projects in all industrial settings.

First is Validation, which is the formal acceptance that all requirements have been addressed or fulfilled—the system was built the way it was expected with all the desired subsystems and other components. This will be the formal result of the design and development documentation.

Second is Verification, which confirms that the system actually works the way the business process requirements and SMEs desired—data taken in, analyzed, and processed accordingly, and resulting data disseminated appropriately. This also includes accepting that the vendor has complied with the service level agreements for performance and availability. This will be the formal result of the system and user acceptance testing and corrections.

Third is Certification or Accreditation, which is the approval of the ISPs that the enterprise and system/infrastructure security is in place and operating as expected. Some industry sectors and public organizations may require an Accreditation signifying that an authorized board of review has granted the approval based on conformance to expected thresholds or service expectations. This will be the formal result of the final security assessment, including the vulnerability controls evaluation and the review of the business continuity tests.

After all such final hurdles, the senior executive responsible for the new system will formally sign the acceptance and authorize the initiation of the live production operations environment. This will trigger the final payments to the vendor for the system.

For most of the project participants, this is the end of a (relatively) long journey. For ISPs, the initiation of live operations is not the ending, but the true beginning—the beginning of information security discipline! After live operations begin, the calendar for postoperational assessments begins (based on regulatory requirements), and the ISPs will be tracking the project requirements for adjustments made in the first few months (very few large systems operate flawlessly in the first weeks/months). Any change or correction must follow the project change management process, which will entail reviews, signatures, and assurance that separation of duties is enforced. Depending on the organization and the nature of the system, regulatory audits and assessments will be scheduled for the first year. Some industry certifications or accreditations may not be awarded until after the system has been operational for several months. ISPs will also begin the periodic reviews of logs and error files and the tracking of the reported incidents in hopes of avoiding major interruptions. ISPs will also begin the tracking of expected changes to the software system and to the infrastructure/architecture based on normal growth in the organization.

Working through the design of an enterprise security structure for an LSDP provides a more complete perspective on the management of information security through time. Compelled to view the structure end-to-end, one is able to understand the limitations and inhibitions of the classic, task-oriented, compartmentalized view of information security. In many settings, the information security role is considered part of the IT organizational unit; all other organizational users defer to the technical unit for security information. Its focus is operational or tactical, having a monthly-to-yearly planning perspective. The tasks also are short-term oriented—user account management, policy and procedure documentation, user training, etc. More technical ISPs may participate in network access device configuration, device and system log reviews, and incident response and resolution. Some ISPs may target business continuity/disaster recovery planning and testing. Classic information security is interrupt-driven—fire-fighting. It is detection-/response-oriented and is usually measured by how quickly service interruptions can be resolved. In this view, information security is rarely considered part of long-term, strategic planning.

Personally identifiable Information is increasingly becoming a target of attackers because of its increasing value. Because of the increasing regulatory burden, organizations cannot maintain optimal protection of information with a short-term view. It is becoming increasingly apparent that all employees—from the top-down to the end of each hallway—have roles to play in protecting data and information. Protection mechanisms cannot be relegated to purchased products or even to additional technical staff. Protection processes cannot continue to be interrupt-driven, with one-off responses to individual incidents. To gain efficiencies in time and money, information security must be viewed as an organizational strategic emphasis. The administration of an information protection strategy must be separate from the IT unit because of the potential for conflicts in planning. The precedent in financial management is clear—no financial auditor unit would ever be allowed to report to the organizational financial officer.

Table 16.10 Redefining the Information Security Role

As a strategic resource, the ISPs will fill an important and necessary role for designing the protection of information throughout its complete life cycle—from gathering and creating to archiving and destruction. ISPs will offer strategies for technology change management, ensuring that changes do not open new vulnerabilities to the protection mechanisms. As described in this chapter, ISPs will play valuable roles in designing the enterprise security structure. In this mode, the information security resource will be anticipation-oriented, looking forward to determine the effects of organizational change on the information resource.

The short-term operational and tactical efforts will not go away, but they will be coordinated in ways that emphasize the interrelationships of the incidents, taking into account the potential for careful, slow-paced strategy of attackers seeking monetary gain. With the benefit of a strategic view, ISPs can become important organizational collaborators, building bridges among the Privacy and Risk Management groups, the IT technical support staff, the senior-level business and service continuity planners, and the physical security groups involved with emergency response and human safety. From this strategic emphasis, the information security strategic unit will necessarily develop the Discipline of Information Security. Table 16.10 provides a summary view of the classic and necessary views of information security, though the complete story is for another time!

References

Associated Press. IBM says it can’t find hard drives with 2M health records. WRAL Techwire, 2011. http://wraltechwire.com/business/tech_wire/news/blogpost/9270864/ (accessed March 15, 2011).

deBronkart, D. Imagine someone had been managing your data, and then you looked. E-Patient.net.2009.http://e-patients.net/archives/2009/04/imagine-if-someone-had-been-managing-your-data-and-then-you-looked.html (accessed April 1, 2009).

GHIT Notebook. What’s more important, privacy or security? (Based on interview with Dr. Deborah Peel, Patient Privacy Rights). Government Health IT, 2008. http://www.govhealthit.com/blogs/ghitnotebook/350238-1.html (accessed February 27, 2008).

Goldberg, B. N. J. State computers nearly sold with sensitive data. Reuters.com, 2011. http://www.reuters.com/article/2011/03/10/us-computer-snafu-idUSTRE7296KC20110310 (accessed March 10, 2011).

Gorman, S. Broad new hacking attack detected. Wall Street Journal Technology, 2010. http://online.wsj.com/public/page/news-tech-technology.html (accessed February 18, 2010).

Gruener, W. Complete data security a mission impossible, study claims. Tom’s Hardware, 2008. http://www.tomshardware.com/news/complete-data-security-a-mission-impossible-study-claims,4801.html.

Harbert, T. Security fail: When trusted IT people go bad. Computerworld, 2011. http://www.networkworld.com/news/2011/011811-security-fail-when-trusted-it.html (accessed January 18, 2011).

Kiefer, B. Health Net, Inc. Investigating unaccounted-for server drives. News Release, 2011. http://healthnet.tekgroup.com/article_display.cfm?article_id=5529 (accessed March 14, 2011).

Kolakowski, N. Google health accused of inaccuracy in electronic medical records. Information Week, 2009. http://www.eweek.com/c/a/Health-Care-IT/Google-Health-Accused-of-Inaccuracy-in-Electronic-Medical-Records-603668/ (accessed April 13, 2009).

Krebs, B. Hackers break into Virginia health professions database, demand ransom, Washington Post, May 4, 2009.

Murphy, C. IT is too darn slow. Information Week, 2011. http://www.informationweek.com/news/global-cio/interviews/showArticle.jhtml?articleID=229218781 (accessed February 26, 2011).

Murphy, J. C. No one is listening! ISSA Journal, pp. 27–30, May 2009.

Perrin, C. The CIA Triad. Tech Republic, 2008. http://blogs.techrepublic.com.com/security/?p=488.

Ramshaw, E. and Garrett, R. T. Computer crash hinders Texas Attorney General’s Medicaid fraud case. Dallas Morning News, 2008. http://www.dallasnews.com/sharedcontent/dws/dn/latestnews/stories/102308dntswcomputerwoes.3d684d8.html (accessed October 23, 2008).

Rashid, F. Y. Data breaches at Arizona Medical Center makes case for zero trust security. EWeek, 2011. http://www.eweek.com/c/a/Security/Data-Breaches-at-Arizona-Medical-Center-Makes-Case-for-Zero-Trust-Security-571698/ (accessed January 14, 2011).

Rotenberg, M. Privacy vs. security? Privacy. Huffington Post, 2007. http://www.huffingtonpost.com/marc-rotenberg/privacy-vs-security-priva_b_71806.html (accessed November 9, 2007).

Sanchez, J. Security vs. privacy? Reinterpreting the fourth amendment. Ars Technica, 2009. http://arstechnica.com/tech-policy/news/2009/03/from-the-academy-the-end-of-privacy.ars (accessed March 11, 2009).

Schneier, B. Security vs. privacy. Schneier on security, 2008. http://www.schneier.com/blog/archives/2008/01/security_vs_pri.html (accessed January 29, 2008).

Szabo, N. There is no universal security architecture, 1998. http://szabo.best.vwh.net/index.html.

Szabo, N. Trusted third parties are security holes, 2005. http://szabo.best.vwh.net/index.html.

Tom’s Guide. http://www.tomsguide.com/us/data-security,news-563.html (accessed February 11, 2008).

U.S. Department of Health & Human Services. Summary of the HIPAA Privacy Rule, 2003. http://www.hhs.gov/ocr/privacy/hipaa/understanding/summary/index.html (accessed May, 2003).

U.S. Department of Health & Human Services. HITECH Breach Notification Interim Final Rule, 2009. http://www.hhs.gov/ocr/privacy/hipaa/understanding/coveredentities/breachnotificationifr.html (accessed October 2009).

U.S. Government Accountability Office (GAO). Federal Information System Controls Audit Manual (FISCAM). GAO-09-232G, 2009. http://www.gao.gov/special.pubs/fiscam.html (accessed February 2, 2009).

Washington Post. http://voices.washingtonpost.com/securityfix/2009/05/hackers_break_into_virginia_he.html (accessed May 4, 2009).

Zavis, A. and Zavis, R. Former Cedars-Sinai employee held in identity theft, fraud. Los Angeles Times, 2008. http://articles.latimes.com/2008/dec/23/local/me-cedars-sinai23 (accessed December 23, 2008).