Chapter 6

Software Acceptance

6.1 Introduction

Have you ever been caught in a situation where you are not aware of what certain software does in your computing environment due to lack of pertinent documentation, or the need exists to configure the software to run with elevated or administrative privileges after its installation? These situations are far too familiar today, but they could be easily avoided if there were a formal software acceptance process in place.

Before accepting software for deployment into the production environment or release to the customers, it is important to ensure that the software that has been developed or acquired meets required compliance, quality, functional, and assurance (security) requirements. In today’s security landscape, considerations when accepting software must go beyond mere functionality and take security into account as well. Validation and verification (V&V) of just the business functionality are insufficient to accept software for release. It is also critically important to understand the impact that the accepted software will have on the existing computing ecosystem, regardless of whether it has been developed (built) or procured (bought). Security requirements need to be validated and security controls (safeguards and countermeasures) verified by internal and/or independent third party security testing. Software must not be deployed/released until it has been certified and accredited that the residual risk is at the appropriate level. Additionally, in cases where software is procured from an external software publisher, certain nontechnical protection mechanisms need to be in place as acceptance criteria, and these must be validated and verified as well.

6.2 Objectives

As a CSSLP, you are expected to

• Understand the importance of pre- and postdeployment/release acceptance criteria and how it relates to software assurance.
• Be familiar with build considerations that need to be validated and verified before acceptance for deployment/release.
• Be familiar with procurement considerations that need to be validated and verified before acceptance for deployment/release.
• Know about software assurance in acquisitions and understand legal protection mechanisms that need to exist before procuring software.
• Know what software escrow constitutes and the protection it affords to the involved parties.
• Understand the need to measure the impact of the software that will be deployed into the existing computing ecosystem and existing processes.
• Know the difference between certification and accreditation (C&A) and understand how V&V can be used for C&A.

This chapter will cover each of these objectives in detail. It is imperative that you fully understand not just what software acceptance means, but also how it applies to the software that your organization builds or buys.

6.3 Guidelines for Software Acceptance

Software acceptance is the process of officially or formally accepting new or modified software components that, when integrated, form the information system. Objectives of software acceptance include

• Verification that the software meets specified functional and assurance requirements
• Verification that the software is operationally complete and secure as expected
• Obtaining the approvals from the system owner
• Transference of responsibility from the development team or company (vendor) to the system owner, support staff, and operations personnel if the software is deployed internally

It must, however, be highlighted that, just because software is engineered with security in mind, it does not necessarily assure that the software will be secure when it is released or deployed into what is most often a heterogeneous computing environment. Rarely is software deployed in a stand-alone setting.

Some of the guiding principles of software ready for release from a security viewpoint are given below. Software accepted for deployment or release must

• Be secure by design, default, and deployment (Howard and LeBlanc, 2003)
• Complement existing defense in depth protection
• Run with least privilege
• Be irreversible and tamper-proof
• Isolate and protect administrative functionality and security management interfaces (SMIs)
• Have nontechnical protection mechanisms in place

The mantra for defense in depth, commonly referred to as the SD3 initiatives for software security, ensures that the software is secure not only in design and by default, but also in deployment. Software that does not complement existing defense in depth principles must not be accepted for deployment. For example, if you have certain ports and protocols disabled for security reasons in your computing environment, the introduction of new software must not require the disabled ports and protocols to be enabled, unless when doing so proper security controls are designed to address the increased attack surface area. Software accepted should be able to run without having the need for elevated privileges. By default, the principle of least privilege must apply.

Reverse engineering protection mechanisms with contractual enforcement must be verified to ensure that competitors and hackers are deterred from figuring out the internal design and architectural details of the software itself, which will allow them to circumvent any protective mechanisms that are built in. Unfortunately, what is prevalent in the industry today to deter reversing are ineffective click-through end user licensing agreements (EULAs) with a “You shall not modify, translate, reverse engineer, decompile, or disassemble the software” clause, as depicted in Figure 6.1. The EULA is usually presented upon installation as a splash screen or upon login as a login banner. Software manufacturers deem the clicking of the EULA’s “I agree” to be contractually binding, and the Digital Millennium Copyright Act (DMCA) considers some instances of reverse engineering as criminal offenses, but this is a deterrent control and is not preventative in nature. Reverse engineering protection is increased by code obfuscation and anti-tampering techniques (Eilam, 2005), which must be verified in the software before being accepted for release. Reverse engineering is also known as reversing or reverse code engineering (RCE).

Administrative functionality and SMIs need to be validated as being accessible only to those individuals who have the need for them, a small subset of users whose actions are also audited and reviewed periodically.

Additionally, software must not only first meet functional requirements, but also must include all applicable technical security protection mechanisms (architected using secure design principles and developed including elements of the security profile) and have nontechnical protection mechanisms, such as legal protections and escrow, in place before being considered ready for deployment or release.

6.4 Benefits of Accepting Software Formally

The incorporation of a formal software acceptance process based on security is vital in the deployment or release of secure software. This is the final checkpoint for discovering the existence of missed and unforeseen security vulnerabilities and for validating the presence of security controls that will address known threats. Validating that security requirements are included in the design (for software built in-house) or in the request for proposals (RFPs) (for commercial off-the-shelf [COTS] software) and verifying that they have been addressed ensures that security does not need to be bolted on at a later stage after release. It not only ensures that software security issues are proactively addressed and that the software developed is operationally hack-resilient, but also that the software is compliant with applicable regulations. The software acceptance process helps to maintain the secure computing ecosystems by ensuring that new software products have achieved a formally defined level of quality and security. Software not meeting these requirements should not be approved for release into the secure computing ecosystem.

Legal and escrow mechanisms that are validated as part of the software acceptance process also ensure that the software publisher or acquirer is protected. In a nutshell, software acceptance can assure that the software is of high quality, reliable (functioning as expected), and secure from threats.

6.5 Software Acceptance Considerations

We have established the fact that a formal software acceptance must be in place, regardless of how insignificant one may feel this process to be. So what are some of the activities that need to be performed during the software acceptance phase? Software acceptance considerations to be taken into account vary depending on whether the software is built in-house or bought from an external software publisher. In this section, we will first learn about what one needs to consider when building software in-house before certifying the software as ready for deployment/release, and then cover assurance in the procurement methodology and protection mechanisms that need to be considered when buying software.

6.5.1 Considerations When Building Software

Some of the major items to consider before accepting software that is built in-house for deployment/release are illustrated in Figure 6.2. They are described in more detail in this section.

6.5.1.1 Completion Criteria

Functional and security requirements should have been captured in the requirements gathering phase of the software development life cycle (SDLC), and at this stage in the SDLC they need to be validated and verified as complete. Completion criteria for functionality and software security with explicit milestones must be defined well in advance. As a CSSLP, you are particularly interested in the milestones pertinent to security besides functionality. Some examples of security-related milestones include, but are not limited to, the following:

• Generation of the requirements traceability matrix (RTM) that includes security requirements besides functional requirements in the requirement phase (Stackpole, 2010)
• Completion of the threat model during the design phase
• Review and sign-off on the security architecture at the end of the design phase
• Review of code for security vulnerabilities after the development phase
• Completion of security testing at the end of the application testing phase
• Completion of documentation before the deployment phase commences

Each of these milestones must include the actual deliverable (e.g., RTM, threat model, security architecture design, code review report, security test report) that can be tracked. The existence and accuracy of these deliverables need to be verified. At the end of the requirements phase, the software requirements traceability matrix must include the security requirements as well. The threat model should be complete with documented threat lists and associated controls. The architecture review sign-off before code is written should include the various components of the security profile and principles of secure design. Verification of these components and principles must be conducted before acceptance. Code review for security issues must be conducted, and the issues that were identified in the review need to be fixed and tested in the testing phase. Achievement of these milestones is indicative of the state of security in software that is built. If any of these milestones is not completed, then serious thought needs to be given as to whether or not the software is ready for deployment/release, and appropriate risk-based actions need to be taken.

6.5.1.2 Change Management

Change management is a subset of configuration management. Changes to the computing environment and redesign of the security architecture may introduce new security vulnerabilities, thereby increasing risk. Necessary support queues and processes for the software that is to be deployed/released should be established.

Newer versions of software need to be approved, tracked, and validated to ensure that the current state and level of security in the software has not been reduced. If this is the first version of the software being deployed, then it must be recorded in the asset management database. If this a version release, then the asset management database must be updated before accepting the software for release.

Changes should not be allowed unless the appropriate authorities formally approve the change. Authorities should refrain from approving any change requests that have not communicated exactly what the residual risk is or if they do not completely understand the repercussions resulting from the change. Change requests should be approved based on risk and not on the grounds of schedule pressures, as is often observed to be the case.

All changes need to be formally requested by the software development organization, which is usually done through the Program Management Office (PMO). It must then be evaluated for approval or rejection by members of the Configuration/Change Board (CCB).

As part of the software acceptance process, it must be verified that

• Change requests are evaluated for impact on the overall security of the software.
• The asset management database is updated with the new/updated software information.
• The change is requested formally, and evaluated and approved by appropriate signatory authorities.

6.5.1.3 Approval to Deploy/Release

It cannot be overstressed that, without approvals, no change should be allowed to the production computing environment. Before any new installation of software, a risk analysis needs to be conducted and the residual risk determined. The results of the risk analysis along with the steps taken to address it (mitigate or accept) must be communicated to the business owner. The authorizing official (AO) must be informed of the residual risk. The approval or rejection to deploy/release must include recommendations and support from the security team. Ultimately, it is the AO who is responsible for change approvals.

The software acceptance process should validate that approvals are not merely a “check in the checkbox” kind of activity, but that it includes review and oversight through an established governance process for maximum effectiveness. Approvals must be documented and retained.

6.5.1.4 Risk Acceptance and Exception Policy

Since the likelihood of “zero” or “no” risk is utopian, risk that remains after the implementation of security controls (residual risk) needs to be determined first. The best option to address total risk is to mitigate it so that the residual risk falls below the business-defined threshold, in which case the residual risk can be accepted. Risk must be accepted by the business owner and not by officials in the IT department.

For consistency, it is advisable to use the same template when accepting the risk. A risk acceptance template must include at least the following elements: risk, actions, issues, and decisions (RAID). The risk section is used to inform the business of the probability of an unfavorable security situation’s occurring that can lead to disclosure, alteration, or destruction outcomes. Since it is the business owner that accepts the risk, the description in this section must be void of technical jargon. It must be explanatory in describing the risk to the business. The actions section in the risk acceptance document assists the IT and software development management teams by informing them of the steps that have been taken and the steps that are to be taken. The issues section provides the development teams with the technical details of how the threats to the software can be realized, and the decisions section provides management and the AO the options to consider when accepting the risk. An example of a RAID risk acceptance template is illustrated in Figure 6.3.

How residual risk is handled depends on factors such as time and resources. In situations when you do not have the time or resource to mitigate the risk, it is best to transfer or avoid the risk. Risk transference can be achieved by transferring the risk to someone else, such as an insurance company. Risk avoidance can be achieved by discontinuing the use of the software (Kocher, 2004).

However, in certain situations, the risk that is observed is not as a result of security vulnerabilities in the software, but is attributable to noncompliance with a new policy instituted to address the changing security landscape. You also may not have the option to discontinue the use of the newly discovered noncompliant software, which means you cannot avoid the risk of noncompliance. For example, a legacy software very critical to the business cannot comply with the newly instituted 256-bit cipher strength advanced encryption standard (AES) for cryptographic functionality because it supports a maximum of 40 bit cipher strength. In such situations when you cannot mitigate, transfer, or avoid the risk, the best option is to accept the risk with a documented exception to policy. An exception to policy must, however, be allowed if and only if there exist contingency plans with explicit dates specified to address the risk. It is also advisable that the members of the exception review board include subject matter experts from different teams, such as the business (client or customer), software development team, networking team, legal team, privacy team, and the security team.

Accepting risk with an exception to policy has certain benefits. The first and foremost is that business operations are not disrupted. Second, the exception to policy and risk documentation can be used as an audit defense when external auditors determine that your organization is not compliant with policy.

The software acceptance process must ensure that risk management processes are thoroughly followed, that risk is within acceptable thresholds, and an exception to policy exists, if needed, before the software can be deployed or released.

6.5.1.5 Documentation of Software

Often overlooked or receiving little attention, documenting what the software is supposed to do, how it is architected, how it is to be installed, what configuration settings need to be preset, and how to use and administer it is extremely important for effective, secure, and continued use of the software. Some of the primary objectives for documentation are to make the software deployment process easy and repeatable, to ensure that operations are not disrupted, and to take care that the impact upon changes to the software is understood.

Although documentation is a key deliverable at the end of the SDLC predeployment process, it is best advised to commence and complete documentation at each phase. Unfortunately, this is often the most overlooked part of the SDLC, and without appropriate documentation, software must not be accepted for deployment or release.

A fundamental consideration for software acceptance is the existence and completeness of software-related documentation.

Table 6.1 tabulates some of the types of documents that need to be verified as complete.

What is documented should clearly articulate the functionality and security of the software code so that it allows for maintainability by the support team. It is advisable to include members from the support team to participate in observatory roles during the development and testing phases of the SDLC so that they are familiar with the operations of the software that they are expected to support.

It is important to document not just the first version of the software, but also subsequent version releases. This ensures that changes to the software are traceable back to requirements and customer requests.

To ensure that there are no disruptions to operations, critical software must be included in the Business Continuity Plan (BCP) or Disaster Recovery Plan (DRP). The incorporation of new software into the existing BCP/DRP is directly proportional to the importance of that software to the business.

It is also imperative to ensure that the Incident Response Plan (IRP) is available to the operations team. The IRP should include instructions on how to handle an unfavorable event resulting from a software breach. The effectiveness of an IRP is dependent on user awareness and training for how to respond in the event or suspicion of a security incident. Training takes documentation to the people. The dos and don’ts for incident response are covered in more detail in Chapter 7.

6.5.2 When Buying Software

If it has been determined that the benefits of purchasing software are more than the benefits of building the software in-house, a buy decision naturally is made. However, procurement of COTS software from an external software publisher is in and of itself a time-intensive and complex process. It requires a joint collaboration between several teams, such as business, IT software development, legal, and security, and also the vendor. It is crucial to make sure that the benefits gained from procuring software are not annulled by software that is not hack-resilient, thereby putting the organization at risk. Those involved with software procurement (acquisitions) must already be familiar with the fact that software that is not developed in-house requires customization to operate as expected within their environment. The return on investment (ROI) when purchasing software must also factor in the total cost of ownership (TCO), which includes the cost of support and maintenance and the investment of time and resources necessary to incorporate security when it is deployed within your organization’s computing ecosystem. Before accepting software from the vendor, the acquisition phase or phases of the SDLC should include an assessment of security functionality in the software. Vendor claims for security in their software need to be verified. Overall systems assurance evaluation must include the evaluation of the software security as a part of software assurance throughout the acquisition process, as depicted in Figure 6.4.

It is advisable to have a separate software procurement policy, if your organization does not already have one. It must be recognized that the mere existence of a software procurement policy provides no software assurance, unless the policy is developed and followed consistently with best practices in security and compliance requirements. The vendor must be required to demonstrate that basic security tenets of confidentiality, integrity, and availability as well as other components of the security profile are factored into the design and development of the software they are selling, besides ensuring compliance to legal and international requirements. For example, if the software you are procuring will deal with processing and transmitting credit card information, the software must be able to assure confidentiality by protecting sensitive information using cryptographic functionality and also be compliant with Payment Card Industry Data Security Standard (PCI DSS) requirements.

International factors of the software that is being considered for purchase are also very important from a security vantage point. For example, if the software you are purchasing should provide support for international languages that are not of the western script type, then Unicode support and functionality need to be carefully scrutinized. Support of Unicode can arguably be said to double the attack surface since, unlike ASCII, which stores each character in a single byte, Unicode requires 2 bytes to store a character. Other international factors that require consideration include export regulations, cryptography strength standards, and outsourced development.

With a rise in globalization, outsourcing software development to companies and countries with access to cheap labor and intellectual capital has become a trend. Since the organization that outsources (outsourcee) has minimal to no control over the software development process of the outsourcer, extra attention needs to be given to software security in such situations. In outsourcing engagements, it is imperative to ensure the existence of protection mechanisms such as:

Contractual obligations: Contracts must first be established between the outsourcee and the outsourcer so that the outsourcee is provided coverage against liabilities arising from the outsourcing provider.

Secure SDLC: If possible, the outsourcee must require the vendor to integrate security into their SDLC.

Code verification: Before the implementation of software, it is vital that software (source code and object code) security controls are verified, and that it does not have vulnerabilities, such as backdoors, maintenance hooks, or logic bombs. The best way to detect such embedded code security issues is by code review.

Additionally, beware of evaluating software by checking a list of checkboxes that the vendor claims are security functionality in their software. Checklists do not secure. If your vendor claims that their software supports strong encryption, ask them to define “strong” instead of assuming what they mean. What they mean by “strong” may not, in fact, meet your organizational policy requirements, or it may be incompliant with industry regulations and standards. Verify that the cryptographic functionality in their software is indeed “strong,” meeting your organizational requirements and being compliant with industry standards.

6.5.2.1 Procurement Methodology

Security of purchased software is closely tied to its procurement methodology. Specifying security requirements in the procurement methodology has a directly proportional relationship to the security of the software that is purchased. In other words, if the procurement methodology does not factor security into its requirements, the likelihood is high that the software you purchase will be insecure. So it is critical that, as part of the software acceptance process, the methodology employed in procuring software is carefully scrutinized and validated to ensure that security requirements are included and implemented appropriately.

The most common means by which organizations solicit software vendors is by initiating an RFP or a request for information (RFI) and, in some cases, a request for quote (RFQ). In other cases, the purchasing organization partners with the vendor and codevelops the software, but this practice is not as prevalent. Regardless of whether your organization is in the commercial, private, or government sector, when it comes to procuring software or software services from software publishers (vendors), the RFP methodology is the de facto standard in software acquisition. The software acquisition process is fairly direct and simple, as illustrated in Figure 6.5.

6.5.2.1.1 RFPs and Software Assurance

RFPs can be a valuable mechanism to ensure that solutions delivered by the vendor are useful and applicable to the business needs of your organization. It is only recently that the importance of the security in the software being purchased is reflected by the incorporation of security requirements in the RFPs.

Listed below in this section are some guidelines for effective issuance and evaluations of RFPs. These guidelines are:

• It is vital that, besides functional requirements that are specified in the RFP, which is usually the case, security requirements are explicitly stated as well. By clearly defining requirements, those participating in the RFP process will be clear on what your expectations are, leaving little room for guesswork.
• RFPs responses must be time-bound. This means that the time that is allowed for responding to the RFPs must be adequate for vendors to make a solid proposal, but at the same time must not be inordinate. Provisions for late offers must be explicitly defined and stated, if allowed. This way, timely responses are tied directly to the specified requirements, and security vulnerabilities arising from changing requirements (scope creep) are reduced.
• Evaluation criteria must be predefined and the evaluation process must be explicitly stated in the RFP. Some examples of evaluation criteria that are commonly observed in RFPs is how well the responses demonstrate:
  • An understanding of the requirements
  • A solution concept
  • Experiences of personnel
  • Valid references from past performance
  • Resources, cost, and schedule considerations

It is also important to evaluate the responses to the RFP based on how it addresses software assurance as part of the solution concept. It is important to use the same evaluation criteria and rank the responses using the same scoring mechanism so that the evaluation is fair, uniform, and consistent. Additionally, it is wise to include evaluators from various teams (e.g., software development, networking, operations, legal, privacy, security) so that adequate and appropriate subject matter expertise (SME) may be applied when evaluating the proposals.

6.5.2.1.2 Vendor Evaluations

Not only must the responses be evaluated, but the vendor who submitted the response must also be evaluated. Before accepting the software and issuing a purchase order, the vendor’s SDLC and evidence of incorporating security in the vendor’s SDLC, qualification of their personnel and their security know-how, support and maintenance model, and availability of independent references need to be evaluated.

• Vendor SDLC: The software vendor’s SDLC process must be investigated to ensure that they have a structured process that incorporates security into the software they build. Some questions to ask the vendor are: How is the software development process structured? What are some of the artifacts generated? Do you outsource your software development, and if so, what checks and balances exist that require validation? How current and accurate is the documentation that comes with the software?
• Evidence of Security in the Software: Evidence of incorporating security in the vendor’s SDLC needs to be verified. Some questions to ask the vendor are: Do you have a threat modeling process, and is there a threat model for the software you are proposing? What kind of reviews (design, architecture, code) do you conduct? How is the software tested against functional and security requirements? Has the software been attested and certified as secure by an independent third party? By understanding the vendor’s SDLC process and how security is addressed through the different phases, one can get an insight into the secure state of the software one is purchasing.

  Never take the vendor’s claims for granted. Always verify their claims. Verification of assurance (security) starts with first determining if there are any known vulnerabilities in the vendor’s software. Full disclosure lists and security bug tracking lists can help in this regard. Verifying claimed security features in the vendor software can also be achieved by black box penetration testing. This is usually the only way to attest third party software, since you do not have access to the source code, and reverse engineering the object code will be illegal. You must conduct black box tests against software that you have not yet purchased only after you have communicated to the vendor your intent to do so and legally received their approval. It is always advisable to have an independent third party perform this assurance check so that there is objectivity and neutrality. To avoid potential security issues after release, assurance checks are extremely critical steps that cannot be overlooked or taken lightly.

• Personnel Qualifications: Close attention should be given to ensure that those who will be responsible for developing the software solution and incorporating security into the software are adequately qualified and familiar with new generation and current threats. Some questions to ask are: What is your training program and the frequency in which your employees (and nonemployee personnel) are trained in the latest security threats and controls to address those threats?
• Support and Maintenance Model: Vendor support and maintenance model must be reviewed to ensure that the vendor will be able to support, maintain, and release patches in time when security vulnerabilities are discovered in their software. One of the core software security concepts is the need to ensure that the software will be available when needed. An important consideration in this regard is to determine the service level agreement (SLA) to fix vulnerabilities.
• Independent References: The past performance of the vendor must be evaluated. You must request a list of references from customers of the vendor and make interview calls to verify the validity of vendor claims (Baschab and Piot, 2007). You can also determine if the vendor is willing to undergo an independent third party assessment.

RFP responses evaluation and vendor evaluation are both essential activities that need to be taken into account as part of the software acceptance process before buying the software. Acceptance criteria must be predefined, and only upon complete evaluation and validation that the software will satisfy the acceptance criteria should the purchase order be issued. Table 6.2 provides an example of generic acceptance criteria as listed in the Software Assurance in Acquisitions: Mitigating Risks to the Enterprise prepublication document.

6.6 Legal Protection Mechanisms

Besides an understanding of the procurement methodology and its impact on software security, a working knowledge of legal concepts related to information technology is required to understand fully the nontechnical threats and risks inherent with software. When these legal concepts are addressed, they protect not only the software purchaser, but also the software producers and related stakeholders engaged in the development and use of the software. In this section, we will discuss each of the legal protection mechanisms that are pertinent to software assurance. These include:

• Intellectual property (IP) protections
• Disclaimers
• Validity periods
• Contracts and agreements
• Software escrow

6.6.1 IP Protection

The software publisher, whether it is your organization or the organization from which you purchase the software, has the responsibility to protect the software it produces so that it does not lose its creation or competitive advantage to someone else. The World Intellectual Property Organization (WIPO) defines intellectual property as the creations of the mind. These include inventions, literary and artistic works, symbols, names, images, and designs that are used in commerce. IP is of two types, and the most common software-related IP categories are depicted in Figure 6.6.

Exhaustive coverage of IP protection topics is beyond the scope of this book, so in the following section, basic IP concepts and their intersect with software security will be covered. It is advisable for a CSSLP to work closely with the legal team when consulting on IP-related areas.

6.6.1.1 Patents (Inventions)

As the strongest form of IP protection, patents protect an invention by exclusively granting rights to the owner of a novel, useful, and nonobvious idea that offers a new way of doing something or solving a problem. Patents are given to the owner for a specified period of time, which is usually about 20 years, and after that time has elapsed, the patent is said to have expired and the item enters into the public domain, which means that that owner no longer has exclusive rights to the invention. The rights that are granted to the owner ensure that the invention cannot be commercially made, used, distributed, or sold without the owner’s consent. Upon mutual agreement, the owner can grant permission to license to use or sell the invention to other parties. The invention may be a product or a process and is patentable as long as it meets the following conditions:

• It must be of practical use.
• It must be novel, with at least one new characteristic that is nonexistent in the domain of existing knowledge (technical field). In other words, there must be no prior-art.
• It must demonstrate an inventive step.
• It must be compliant with the law and deemed as acceptable in a court of law, usually in the country of origin and filing, since the jurisdiction for patents is not international, although they may be recognized worldwide.

Besides providing recognition of one’s creativity and reward for inventions that are marketable, patents encourage innovation to determine better and newer ways of solving problems.

The debate on the patentability of software-related inventions is ongoing. In some countries, software is deemed patentable, whereas in others it is not. It is best advised to review the patentable guidelines for the country in which you file the software and to consult with an IP legal representative. However, computer programs may be protected under copyright.

6.6.1.2 Copyright

Copyright protects the expression of an idea and not the idea itself. It gives rights to the creator of literary and artistic works and architectural design. It includes the protection of technical drawings, such as software design and architecture specifications, that express the solution concept. While granting the creator with the exclusive rights to use, copyright also grants the creator rights to authorize or prohibit the use, reproduction, public performance, broadcasting, translation, or adaptation of their work to others. Creators can also sell their rights for payments referred to as royalties. Like patents, copyrights also have an expiration, which is nationally defined and usually extends even beyond the death of the creator, usually for about 50 years, as a means to protect the creator’s heirs.

Unauthorized copying, illegal installations, and piracy of software are direct violations of the copyright laws against a creator. Peer-to-peer-based torrents’ unauthorized sharing of copyrighted information also constitutes copyright violations. To protect against copyright infringement, it is advisable to design and develop your software so that it actively solicits acceptance of terms of use and licensing by presenting the EULA with “I accept” functionality. It must, however, be recognized that the EULA acceptance may only deter copyright infringement and not prevent it.

6.6.1.3 Trademark

Trademarks are distinctive signs that can be used to identify the maker uniquely from others who produce a similar product. UPS Brown, Intel’s Pentium processor, and McDonald’s golden arches are good examples of trademarks. When this is for a service, it is referred to as a service mark. The maker can be a specific person or an enterprise. The trademark can be a word, letter, phrase, numeral, drawing, three-dimensional sign, piece of music, vocal sound, fragrance, color, symbol of design, or combinations of these. Trademarks grant owners exclusive rights to use them to identify goods and services or to authorize others to use them in return for monetary remuneration for a period of time. The period of protection varies, but trademarks can be renewed indefinitely.

The protection of trademarks from infringement is based on the need to clarify the source of the goods or service exclusively to a particular supplier, but by definition, a trademark enjoys no protection from disclosure, because only when a trademark is disclosed can the consumers associate that trademark to the goods or services supplied by the company. On the other hand, before disclosure of a trademark, a company may need to protect the confidentiality of the trademark until it is made public, in which case it would be deemed a trade secret.

6.6.1.4 Trade Secret

A trade secret is not just limited to protection of a trademark, but is broadly inclusive of any confidential business information that provides a company with a competitive advantage. It can be a design, formula, instrument, method, pattern, practice, process, or strategy, as well as supplier or client lists that bear the following characteristics:

• The information must not be generally known, readily accessible, or reasonably ascertainable.
• It must have commercial value that is lost or reduced should the information be disclosed.
• It must be protected by the holder of the information (e.g., through confidentiality agreements).

Examples of well-known trade secrets include the formula for Coca-Cola, Colonel Sanders’ fried chicken recipe, and Microsoft Windows operating system code. Even your software code may need to be protected as a trade secret if disclosure of the code will result in an unfair loss of your competitive advantage. The entire software code may need to be protected as a trade secret, or perhaps just portions of your code. Just because your software is deployed in object code form does not imply that trade secret protection is automatically present. Nondisclosure agreements (NDAs) are legally enforceable and must be in place with all developers who are writing such business-critical software. Additionally, protection against RCE should be architected and designed into the software because RCE can yield knowledge about the design and inner workings of the software and is, therefore, a potential threat to the confidentiality of trade secrets.

6.6.2 Disclaimers

IP protection mechanisms protect the company against known threats and scenarios. However, in the world of software, anything can go wrong at any time, and there are many unforeseen situations that can arise. For example, the installation of your software in a client system may require a certain configuration of the host operating system. Such configuration settings, however, have been known to put the client system in a state of compromise. Although it is not your software that is vulnerable, the state of security of the system has been reduced, and upon breach, you can be held liable for the breach. This is where disclaimers come in as a protective means. Disclaimers provide software companies legal protection from liability claims or lawsuits that are unforeseen. When selling or purchasing software, careful attention must be paid to disclaimers. Disclaimers protect the software publisher by informing the purchaser that the software is sold “as is.” They shift the risks from the publisher to the acquirer, and for any unfortunate security incident that arises as a result of using the software, the publisher will not be held legally accountable.

A prevalent application of disclaimers today is in the context of Web applications, when a popup message appears informing the user that they are leaving the Web site they are on to another Web site to which they have linked. Figure 6.7 is an example of a disclaimer popup. When linking to an external Web site or listing contents from another Web site (as is the case with mashups), it is also imperative that appropriate permissions from the owner of the external Web site are explicitly obtained to avoid copyright and other liability concerns.

6.6.3 Validity Periods

You will have noticed that you can run some software, especially in the cases of “try before you buy” or “demo” software versions, only for a set period of time before the software is set to expire. Validity periods refer to the allowed length-of-use of the software or the outputs from the software. For example, if your software is used to print an invoice, then it is important that you explicitly state the number of days or hours that the invoice will be honored. This way, someone who prints an invoice with a discounted price does not hold you liable after the stated period has passed and take advantage of the offer when the product is not offered anymore at the discounted price.

Restrictions should be placed in the software to ensure that the software is not allowed continuance of use once the expiration has elapsed, unless the user purchases the software or agrees to your conditions. It is very important that the software is designed and deployed securely with regard to validity periods. It is advisable that, in the design of the trial and full version of the software, the extent of functionality is considered and addressed. The trial version of the software must not include the full functionality of the purchased version, which is merely protected by a license or expiration date check. This way, even if a software license or expiration data check is circumvented, full functionality of the software is not disclosed. RCE, byte patching (changing instruction sets of the program at the byte level), and repacking of the software program can be used to invalidate and bypass license and expiration date checks easily.

Licensing, either by establishing master agreements or EULAs, is a means to set out and communicate the conditions of use along with any restrictions for the software. Master agreements are broad and set out the general overall conditions of use along with any restrictions, and EULAs add granularity to these conditions and restrictions.

Another aspect of validity periods as they apply to software is with regard to logic bombs. This is especially important if you have outsourced your software development to an external third party. Logic bombs, which are embedded code that executes when certain conditions have been met, need to be discovered and addressed. One such condition may be the length-of-use term, and the trigger for the execution of the embedded code would be the time period. A programmer can embed in your software a piece of code that would render the software nonfunctional once the validity period has passed. Although this is needed to ensure discontinuance of use of the software post validity periods, it could also backfire and cause a denial of service (DoS) to valid customers if such protection mechanisms are not required in the first place. Careful thought and design need to be factored into the concept of validity periods in software.

6.6.4 Contracts and Agreements

Contracts protect an organization from liabilities that may arise against the organization. These are legally binding agreements, which means that the terms and conditions will hold up in a court of law, and violators can be penalized for violation of the terms and conditions. Unlike disclaimer-based protection, wherein there exists only a one-sided notification of terms, contracts require that both parties engaged in the transaction mutually agree to abide by any terms in the agreement. It is essential to have contracts in place when you outsource the development of your software or if you are developing the software exclusively for a particular customer.

In addition to contracts, there are other agreements that offer protection and software assurance. The ones covered in this section are:

• Service level agreements
• Nondisclosure agreements
• Noncompete agreements

This section is not inclusive of all the types of agreements but it covers the main agreements that relate to software development. Data classification exercises are useful in defining and classifying the information and the elements of SLAs or NDAs in protecting that information.

6.6.4.1 Service Level Agreements (SLA)

SLAs are formal agreements between a service provider and a service recipient. They may include incentives and penalties, in which case they are deemed to be more in the nature of contracts.

SLAs are “requirements-dependent” and “requirements-based.” Being requirements-dependent implies that the SLAs must include the requirements of the business. For example, a payroll system cannot suffer downtime, unlike a noncritical human resources training system. Being requirements-based means that, without clearly defined requirements, determination of actual service levels in the formulation of the SLA will be inaccurate. Data classification exercises can be useful in determining the requirements. For example, by classifying information based on criticality to the business, the maximum tolerable downtime (MTD) and recovery time objective (RTO) can be determined, which in turn can be used to determine and define the availability conditions of the SLA.

SLAs have a direct bearing on the TCO because they are the instrument that can be used to ensure support and maintenance by the software service provider. When accepting software for deployment, it is critical that all SLA terms and claims are verified. SLAs are usually observed to be more closely related to the availability tenet of security, but SLAs can address other elements of the security profile, including confidentiality and integrity. SLAs drafted with a time to respond provision, such as “severity 1 incidents will warrant a 1-4 hour workaround” and “severity 2 incidents will be serviced within 4-24 hours,” are not uncommon.

Performance on the SLA is measured using metrics. Table 6.3 tabulates several common SLA metrics associated with what they cover.

6.6.4.2 Nondisclosure Agreements (NDA)

NDAs are basic legal protection mechanisms that ensure confidentiality of information. They protect individuals and organizations against inappropriate, unauthorized, and unlawful disclosure of their proprietary or confidential information that the other party is made aware of so that they may conduct business with each other. Most effective NDAs are mutual, implying that both the disclosing party and the receiving party are protected from their own information’s being disclosed without appropriate permissions. Mutual NDAs promote equality in the protection of information.

If it is required for you to disclose your invention to a potential investor before a patent can be filed, it is advisable to protect it with an NDA. Additionally, sometimes when conducting business or acquiring software, you are required to disclose information that is classified as confidential or trade secrets and in such cases, it is essential that NDAs are established and in effect.

A typical NDA includes the following:

• Legal name and contact information of the entities (parties) entering into the agreement not to disclose each other’s sensitive or proprietary information that they are privy to in the course of conducting business.
• A commencement date for the agreement to become effective. This is usually the date on which both parties sign the agreement.
• The information that is to be protected. This must be clearly defined. It must not be limited to, but at least include information about the business practices, such as:
  • Business processes
  • Business affairs
  • Client lists and requirements
  • Development plans
  • Strategic alliances
  • Accounting and other financial information.

  It must also be inclusive of software development-related information, such as:

  • Logic and process flowcharts.
  • Functional specifications.
  • Screen layouts and mock-up.
  • Design and architecture documents (e.g., entity–relationship diagrams [ERD], network design, BCP and DRP logical and physical representations, threat models).
  • Diagrammatic representation of functionality (e.g., system context diagrams, use cases, misuse cases).
  • Pseudo-code documents.
  • Formal code (source) and executable (object/compiled) that is developed or deployed.
  • Web site uniform resource locators (URLs) and network Internet protocol (IP) addresses registered by the parties.
  • Ideas, functions, operations, and outcomes of products and services that are owned or currently developed; sometimes this section in the NDA also defines the forms of confidential information and includes oral, written, electronic or other machine readable forms for both the original and translated versions of information.
• Permitted use of the information, such as disclosure only to parties that have a need to know and disclosure to third parties that have a binding equally or more restrictive contractual relationship with the disclosing party for the purposes of doing business.
• Conditions and provisions to disclose information upon mutual written consent.
• Exclusions or no obligation upon a recipient if the confidential information
  • Is or becomes publicly available through no fault of the recipient.
  • Was already in the recipient’s possession before disclosure.
  • Is received rightfully by the recipient from a third party without the duty of confidentiality.
  • Is disclosed to a third party without a duty of confidentiality.
  • Is independently developed by the recipient.
  • Is required by a government body or a court of law; in situations when this is the case, advance notice must be given to the party whose information is being disclosed.
  • A protection period that includes how long the agreement itself will be in effect and also how long the proprietary and sensitive information must remain protected or maintain confidentiality. The length of term to protect the information from disclosure usually extends beyond the life of the agreement itself. This may also require that after the effective term of the NDA, confidential information must be rightfully and securely returned to the owner and originals and copies (if any were made) must be destroyed.
• Other pertinent information. Sometimes the NDA also includes sections on:
  • Export compliance
  • Ownership
  • Remedies
  • Governing law
  • Disclaimers

NDAs are useful instruments in ensuring confidentiality and must be established before any development work if the information is deemed as needing protection.

6.6.4.3 Noncompete Agreements

Noncompete agreements (also known as noncompete clauses) are legally enforceable contractual obligations between a company and an individual or another company that poses a threat to the competitive advantage of the company. This affords protection to the company in situations when a disgruntled employee is fired or when an employee with knowledge of the inner workings of the company leaves the company. It can also be extrapolated to prevent personnel with business and strategic know-how of your company who are solicited by your competitors to leave and work for your competitor, until the term specified in the noncompete agreement has elapsed.

If knowledge about your software is considered a trade secret, then in addition to NDAs, it is vital that noncompete agreements are established and enforced as well.

6.7 Software Escrow

When it comes to acceptance of third party software, consideration must be given to software escrow as well as the legal protection mechanisms that need to exist. Software escrow is the act of having a copy of the source code of the implemented software in the custody of a mutually agreed upon neutral third party known as the escrow agency or party. There are three parties involved in an escrow relationship: the acquirer (licensee or purchaser), the publisher (licensor or seller), and the escrow agency, as depicted in Figure 6.8.

This can be regarded as a form of risk transference by insurance, because it insures the licensee continued business operations, should the licensor be no longer alive (in case of a sole proprietorship), go out of business, or file for bankruptcy. Software escrow guards against loss of use of mission-critical software associated with vendor (publisher) failure. It is also important to understand that software escrow protects the licensor in guarding their IP rights as long as the publisher wishes to retain the rights. The licensee cannot purchase the software or reverse engineer the software to write their own. Determination of whether such a breach has occurred can be established by comparing the software to the copies and versions that are held in escrow.

What is escrowed is dependent on the escrow agreement. It is usually only the source code that is escrowed and so is commonly known as source code escrow. However, it is advisable that versions of both source and object code are escrowed along with appropriate documentation for each version.

One of the main failures in software escrow situations is not the fact that the code (source and/or object) is not escrowed properly, but in the verification and validation processes after the code has been escrowed.

Verification and validation should minimally include the following:

• Retrieval Verification: Can the processes to retrieve the code from the escrow party be followed? Do you have the evidence to prove validity of your identity when requesting to retrieve the escrow versions, and can it be spoofed? Are there change and version control mechanisms in place that protect the integrity of the versions that are held in escrow, and is the check-out/check-in process audited?
• Compilation Verification: Can the source code be compiled to executable (object) code without errors? Do you have a development and test environment in which to compile the source code that is retrieved from escrow?
• Version Verification: Does the source code version that is escrowed match the version of the object code that is implemented in your environment?

Software escrow aids in software acceptance, and as a CSSLP it is important that you understand the processes and steps involved as well as the protection software escrowing affords your organization.

6.8 Verification and Validation (V&V)

The capability maturity model (CMM) for software version 1.1 defines verification and validation (V&V) as the process of evaluating software to determine whether the products of a given development phase satisfy the conditions imposed at the start of the phase. In other words, verification ensures that the software performs as it is required and designed to do. Validation is the process of evaluating software during and/or at the end of the development process to determine whether it satisfies specified requirements. In other words, validation ensures that the software meets required specifications.

Usually verification and validation go hand in hand, and the differences between the two are primarily definitional and matter more to a theorist than to a practitioner. Broadly speaking, V&V refer to all activities that are undertaken to ensure that the software is functioning and secured as required. V&V is a required step in the software acceptance process, regardless of whether the software is built in-house or procured (acquired).

V&V is not an ad hoc process. It is a very structured and systematic approach to evaluate the software technical functionality. It can be performed by the organization or by an independent third party. Regardless of who performs the V&V exercise, the evaluation is basically divided into two main activities: review, including inspection, and testing, as illustrated in Figure 6.9.

V&V should check for the presence of security protection mechanisms to ensure confidentiality, integrity of data and system, availability, authentication, authorization, auditing, secure session management, proper exception handling, and configuration management. In some cases, the software may be required to comply with certain external regulations and compliance initiatives (e.g., FIPS, PCI DSS, or Common Criteria), and proper V&V of these requirements is essential. The request for Common Criteria evaluation assurance levels (EAL) must be in place when procuring software, and the EAL claimed by the vendor must be verified. It is important to note that it is not sufficient simply to check for the existence of security features; the V&V process must verify the correct implementation of the security features that are present. It is superfluous to have a security feature in the software that is accepted, but which is or needs to be disabled when deployed in the production environment or released. V&V can be used for C&A of the software. The following section covers each of the V&V activities in more detail, followed by a discussion on C&A.

6.8.1 Reviews

At the end of each phase of the SDLC, reviews need to be conducted to ensure that the software performs as expected and meets business specifications. This can be done informally or formally.

Informal reviews usually do not involve a review panel or board and can be as simple as a developer’s reviewing his/her own design and code. This is usually performed as needed, unlike a formal review, which is regarded to be a milestone in the SDLC.

The formal review process includes the presentation of the materials to a review panel or board for approval before proceeding to the next phase of the life cycle. Reviews must not be a mere check-the-box exercise wherein the panel simply checks an approval box to proceed to the next phase. The most effective reviews are observed when the personnel who are directly involved in the development of the software present the inner working design and instrumentation of the software to a review panel and answer any questions from the panel. The review panel is appointed by the acquirer of the software who has the authority to make a go/no-go decision and should include at least one member from the team responsible for software assurance.

Informal review may include review of the design and of the code, but formal reviews must include design and code review. One such formal inspection process is the Fagan inspection process, which is a highly structured process with several steps to determine defects in development results, such as specifications, design, and code. In addition to the review of the functionality design, a security design review (using threat models, misuse cases, and so on) must be performed. Design reviews are conducted at the end of the design phase with the goal of detecting any architectural flaw that would require redesign before code is created. Design reviews help in the validation of software. Code reviews happen at the end of the development phase and involve line-by-line review of the code and step-by-step inspection (sometimes also called a walkthrough) of software functionality and assurance capabilities. This is performed with the intent of detecting bugs and errors. Code reviews are usually conducted among peers from development and quality assurance teams and so are also referred to as peer reviews. Code reviews help in the verification of software. Automated code review scanners and data flow tracers can be used to augment more manual and structured inspection processes.

6.8.2 Testing

As a key activity in the V&V process, testing can help demonstrate that the software truly meets the requirements (validation) and determine any variances or deviations from what is expected (verification) using the actual results from the test. It also includes testing to determine the impact upon system integration. The different kinds of tests that are conducted as part of V&V are:

• Error detection tests
• Acceptance tests

Error detection tests include unit- and component-level testing. Errors may be flaws (design issues) or bugs (code issues). In addition to validation tests to ensure that the software satisfies the specified requirements, verification testing must be performed to ascertain the following at a minimum:

• Proper handling of input validation using fuzzing
• Proper output responses and filtration
• Proper error handling mechanisms
• Secure state transitions and management
• Proper handling of load and tests
• Resilience of interfaces
• Temporal (race conditions) assurance checks
• Spatial (locality of reference) assurance and memory management checks
• Secure software recovery upon failures

Acceptance testing is used to demonstrate whether the software is ready for its intended use. Software that is deemed ready should be validated not only for all functional requirements, but also to ensure that it meets assurance (security) requirements. This test cannot be overlooked or ignored and is a necessary milestone before acceptance of the software for deployment or release. Sometimes when software is released in increments, the acceptance test will include a regression test as part of the systems integration testing activity in addition to the incremental acceptance test.

The impact on integration of the different software components for the system can be determined by regression and/or simulation testing. Regression testing is performed to ensure that the software is backward-compatible and that the software does not introduce any new risks to the computing environment. Regression testing involves rerunning previously defined and run acceptance tests and verifying that the results are as expected. Simulation testing gives insight into configuration mismatches and data discrepancy issues and must be performed in an environment that mirrors the environment in which the accepted software will be deployed.

Once software is accepted, any changes to the software must be formally validated and verified. Impacts to existing processes, such as business continuity, disaster recovery, and incident response, must also be determined, and the maintenance and support model must be revisited and revalidated.

6.8.3 Independent (Third Party) Verification and Validation

Independent Verification and Validation (IV&V) or third party assessment of software functionality and assurance is the process in which the software is reviewed, verified, and validated by someone other than the developer of the software or the acquirer. This is mostly the case with software that is purchased. This is commonly also referred to as independent third party testing. The independent part of this type of testing is that the IV&V party can be neutral and objective in reporting their findings, as they have no stake in the success or failure of the software. All IV&V reviews and tests are formal by nature, and rules of engagement must be established in advance and formalized in the form of a contract or legally enforceable agreement.

IV&V is very helpful in validating vendor claims and assists with the compliance oversight process as it transfers the liability inherent from the software risks to the third party that conducts the reviews and tests, should a breach occur once the software has been accepted on grounds of the findings from the IV&V.

6.8.4 Checklists and Tools

It is important to recognize that merely completing checklists with proper verification of existence and validation of proper implementation are insufficient to ensure software assurance. Checklists may help with compliance, but they do not necessarily secure. All items in the checklist that address the functionality and assurance aspects of the software must be verified and validated.

The use of tools (e.g., code review scanners, vulnerability scanners) to evaluate software security is useful from a prioritization standpoint, but careful attention must be paid to false positives and false negatives. Solely relying on tools in lieu of manual V&V checks is not advised because tools cannot completely emulate human experience and decision-making capabilities. True indication of security maturity implies that the tool is part of a more holistic security program and not just the sole measure to secure software. If IV&V is undertaken, then it is important that you are aware of the checklists and tools they use and that you are fully aware of how the independent third party conducted their V&V process.

6.9 Certification and Accreditation

As aforementioned, V&V activities help with C&A. The ISO/IEC 27006:2007 standard specifies requirements and provides guidance for bodies providing audit and certification of an information security management system (ISMS) and is primarily intended to support software accreditation.

Certification is the technical verification of the software functional and assurance levels. Certification, in other words, is a set of procedures that assesses the suitability of software to operate in a computing environment by evaluating both the technical and nontechnical controls based on predefined criteria (e.g., Common Criteria). Security certification considers the software in the operational environment. At the minimum, it will include assurance evaluation of the following:

• User rights, privileges, and profile management
• Sensitivity of data and application and appropriate controls
• Configurations of system, facility, and locations
• Interconnectivity and dependencies
• Operational security mode

Accreditation is management’s formal acceptance of the system after an understanding of the risks to that system rating in the computing environment. It is management’s official decision to operate a system in the operational security mode for a stated period and the formal acceptance of the identified risk associated with operating the software.

Software must not be accepted as ready for release unless it is certified and accredited. At the completion of the V&V process, the evaluator can rate the software on functional and assurance requirements. Once software is rated by an evaluator, it is easier to make a determination as to whether the software is to be accepted or not.

6.10 Summary

In this chapter, we have learned that before built or bought software is labeled as ready for deployment or release, it needs to be formally accepted. Benefits of a formal software acceptance process include the validation of security requirements and the verification of security controls, ensuring that software is not only operationally hack-resilient, but also compliant with applicable regulations. Before the acceptance of software, there are many things that are to be taken into consideration. When building software, some of these considerations include: the satisfaction of the predefined completion criteria, establishment of the change management process, approvals to deploy or release, risk acceptance and exceptions to policy, and the completeness of pertinent documentation. When buying software, the incorporation of software assurance requirements in the procurement methodology must be an important consideration. IP protection means using patents, copyrights, and trademarks. Legal protections using instruments such as contracts and agreements need to be factored in as well before accepting the software as ready for deployment/release. When purchasing software, another protection mechanism that needs to be validated is software escrowing, which protects both the licensor (software publisher) and the licensee (software purchaser). Additionally, software V&V activities must be undertaken for any software that is being accepted, regardless of whether it is built or bought. V&V activities can be performed by the organization or by an independent third party neutral and objective party. They are broadly categorized into reviews (design and code) and testing (error detection and acceptance) and also include regression, simulation, and integration testing, which ensure that the acceptance of the software will not reduce the existing state of operational security and help with evaluating the technical functional and assurance levels (certification). They also provide management with the residual risk levels, allowing them to accept (accreditation) or reject the software. The most important thing to remember is that without a formal software acceptance process, the likelihood that the software will be functionally reliable and at the same time operationally secure is bleak.

6.11 Review Questions

1. Your organization has the policy to attest the security of any software that will be deployed into the production environment. A third party vendor software is being evaluated for its readiness to be deployed. Which of the following verification and validation mechanism can be employed to attest the security of the vendor’s software?

   A. Source code review

   B. Threat modeling the software

   C. Black box testing

   D. Structural analysis

2. When procuring commercial off-the-shelf (COTS) software for release within your global organization, special attention must be given to multilingual and multicultural capabilities of the software since they are more likely to have

   A. Compilation errors

   B. Canonicalization issues

   C. Cyclomatic complexity

   D. Coding errors

3. To meet the goals of software assurance, when accepting software from a vendor, the software acquisition phase must include processes to

   A. Verify that installation guides and training manuals are provided

   B. Assess the presence and effectiveness of protection mechanisms

   C. Validate vendor’s software products

   D. Assist the vendor in responding to the request for proposals

4. Your organization’s software is published as a trial version without any restricted functionality from the paid version. Which of the following must be designed and implemented to ensure that customers who have not purchased the software are limited in the availability of the software?

   A. Disclaimers

   B. Licensing

   C. Validity periods

   D. Encryption

5. Software escrowing is MORE closely related to which of the following risk handling strategy?

   A. Avoidance

   B. Mitigation

   C. Acceptance

   D. Transference

6. Which of the following legal instruments assures the confidentiality of software programs, processing logic, database schema, and internal organizational business processes and client lists?

   A. Noncompete agreements

   B. Nondisclosure agreements (NDA)

   C. Service level agreements (SLA)

   D. Trademarks

7. “As is” clauses and disclaimers transfer the risk of using the software from the software publisher to the

   A. Developers

   B. End users

   C. Testers

   D. Business owners

8. Improper implementation of validity periods using length-of-use checks in code can result in which of the following types of security issues for legitimate users?

   A. Tampering

   B. Denial of service

   C. Authentication bypass

   D. Spoofing

9. The process of evaluating software to determine whether the products of a given development phase satisfies the conditions imposed at the start of the phase is referred to as

   A. Verification

   B. Validation

   C. Authentication

   D. Authorization

10. When verification activities are used to determine if the software is functioning as it is expected to, it provides insight into which of the following aspects of software assurance?

    A. Redundancy

    B. Reliability

    C. Resiliency

    D. Recoverability

11. When procuring software the purchasing company can request the evaluation assurance levels (EALs) of the software product which is determined using which of the following evaluation methodologies?

    A. Operationally Critical Assets Threats and Vulnerability Evaluation® (OCTAVESM)

    B. Security quality requirements engineering (SQUARE)

    C. Common criteria

    D. Comprehensive, lightweight application security process (CLASP)

12. The final activity in the software acceptance process is the go/no go decision that can be determined using

    A. Regression testing

    B. Integration testing

    C. Unit testing

    D. User acceptance testing

13. Management’s formal acceptance of the system after an understanding of the residual risks to that system in the computing environment is also referred to as

    A. Patching

    B. Hardening

    C. Certification

    D. Accreditation

14. You determine that a legacy software running in your computing environment is susceptible to cross-site request forgery (CSRF) attacks because of the way it manages sessions. The business has the need to continue use of this software, but you do not have the source code available to implement security controls in code as a mitigation measure against CSRF attacks. What is the best course of action to undertake in such a situation?

    A. Avoid the risk by forcing the business to discontinue use of the software

    B. Accept the risk with a documented exception

    C. Transfer the risk by buying insurance

    D. Ignore the risk since it is legacy software

15. As part of the accreditation process, the residual risk of a software evaluated for deployment must be accepted formally by the

    A. Board members and executive management

    B. Business owner

    C. Information technology (IT) management

    D. Security organization

    E. Developers

References

Baschab, J., and Piot, J. 2007. Check vendor references. The Executive’s Guide to Information Technology. Hoboken, NJ: John Wiley & Sons, 431–438.

Carnegie Mellon University Software Research Institute. 2011. CMMI models: What is the difference between verification and validation? Web. 4 Mar. 2011. http://www.sei.cmu.edu/cmmi/start/faq/models-faq.cfm (accessed 6 Mar. 2011).

Eilam, E. 2005. Obfuscation tools. Reversing: Secrets of Reverse Engineering. Indianapolis: Wiley, 345.

Howard, M., and LeBlanc, D. 2003. Security principles to live by. Writing Secure Code, 2nd ed. Redmond, WA: Microsoft, 51–53.

ISO/IEC 27006:2007. International Organization for Standardization, 19 Jan. 2011. Web. 04 Mar. 2011. http://www.iso.org/iso/catalogue_detail?csnumber=42505 (accessed 6 Mar. 2011).

Kocher, K. 2004. Creating a Learning Culture: Strategy, Technology, and Practice. ed. Marcia L. Conner and James G. Clawson. Cambridge, UK: Cambridge UP, 63.

Patton, C. 1987. Buyers turning toward software escrow plans. InfoWorld Management 9.43 (1987): 57–58.

SearchSecurity.com. 2004. What is non-disclosure agreement? Web. 4 Mar. 2011. http://searchsecurity.techtarget.com/sDefinition/0,,sid14_gci214435,00.html (accessed 6 Mar. 2011).

Shoemaker, D. 2007. Building security into the business acquisition process. Build Security In. Department of Homeland Security National Cyber Security Division. Web. 4 Mar. 2011. https://buildsecurityin.us-cert.gov/bsi/ (accessed 6 Mar. 2011).

Stackpole, Cynthia. 2010. Requirements traceability matrix. A Project Manager’s Book of Forms: A Companion to the PMBOK Guide. Hoboken, NJ: Wiley, 29.

U.S. Department of Homeland Security. 2008. Software assurance (SwA) in acquisition: Mitigating risks to the enterprise. 2008. Build Security In. Web. 4 Mar. 2011. https://buildsecurityin.us-cert.gov/bsi/articles/best-practices/acquisition/896-BSI.html (accessed 6 Mar. 2011).

U.S. Department of Homeland Security. 2009. Software assurance in acquisition and contract language. 2009. Acquisition & Outsourcing 1.1.1 (2009): 1–27. Build Security In. Web. 4 Mar. 2011. https://buildsecurityin.us-cert.gov/swa/pocket_guide_series.html#acquisition (accessed 6 Mar. 2011).

World Intellectual Property Organization. 2011. What is intellectual property? Web. 4 Mar. 2011. http://www.wipo.int/about-ip/en/ (accessed 6 Mar. 2011).