Chapter 18. Security Activities Across the Technology Life Cycle

This chapter covers CAS-003 objective 5.2

When managing the security of an enterprise, security practitioners must be mindful of security across the entire technology life cycle. As the enterprise changes and new devices and technologies are introduced, maintained, and retired, security practitioners must ensure that the appropriate security controls are deployed. Providing security across the technology life cycle includes understanding both the systems development life cycle and the software development life cycle; adapting solutions to address emerging threats, disruptive technologies, and security trends; and asset management.

The steps in the SDLC are as follows:

Step 1. Initiate

Step 2. Acquire/develop

Step 3. Implement

Step 4. Operate/maintain

Step 5. Dispose

In the initiation phase, the realization is made that a new feature or functionality is desired or required in the enterprise. This new feature might constitute an upgrade to an existing asset or the purchase or development of a new asset. In either case, the initiation phase includes making a decision about whether to purchase the product or develop it internally.

In this stage, an organization must also give thought to the security requirements of the solution. A preliminary risk assessment can detail the confidentiality integrity availability (CIA) requirement and concerns. Identifying these issues at the outset is important so that these considerations can guide the purchase or development of the solution. The earlier in the SDLC the security requirements are identified, the more likely the issues are to be successfully addressed in the final product.

In the acquisition stage of the SDLC, a series of activities provide input to facilitate making a decision about acquiring or developing the solution. The organization then makes a decision on the solution. The activities are designed to get answers to the following questions:

• What functions does the system need to perform?

• What potential risks to CIA are exposed by the solution?

• What protection levels must be provided to satisfy legal and regulatory requirements?

• What tests are required to ensure that security concerns have been mitigated?

• How do various third-party solutions address these concerns?

• How do the security controls required by the solution affect other parts of the company security policy?

• What metrics will be used to evaluate the success of the security controls?

The answers to these questions should guide the questions during the acquisition step as well as the steps that follow this stage of the SDLC.

In the implementation stage, senior management formally approves the system before it goes live. Then the solution is introduced to the live environment, which is the operation/maintenance stage—but not until the organization has completed both certification and accreditation. Certification is the process of technically verifying the solution’s effectiveness and security. The accreditation process involves a formal authorization to introduce the solution into the production environment by management. It is during this stage that the security administrator would train all users on how to protect company information when using the new system and on how to recognize social engineering attacks.

The process doesn’t end right when the system begins operating in the environment. Doing a performance baseline is important so that continuous monitoring can take place. The baseline ensures that performance issues can be quickly determined. Any changes over time (for example, addition of new features, patches to the solution, and so on) should be closely monitored with respect to the effects on the baseline.

Instituting a formal change management process, as discussed in the “Configuration and Change Management” section, later in this chapter, ensures that all changes are both approved and documented. Because any changes can affect both security and performance, special attention should be given to monitoring the solution after any changes are made.

Finally, vulnerability assessments and penetration testing after the solution is implemented can help discover any security or performance problems that might either be introduced by a change or arise as a result of a new threat.

The disposal stage consists of removing the solution from the environment when it reaches the end of its usefulness. When this occurs, an organization must consider certain issues, including:

• Does removal or replacement of the solution introduce any security holes in the network?

• How can the system be terminated in an orderly fashion so as not to disrupt business continuity?

• How should any residual data left on any systems be removed?

• How should any physical systems that were part of the solution be disposed of safely?

• Are there any legal or regulatory issues that would guide the destruction of data?

For the CASP exam, you need to understand how to cover the SDLC from end to end. For example, suppose a company wants to boost profits by implementing cost savings on non-core business activities. The IT manager seeks approval for the corporate email system to be hosted in the cloud. The compliance officer must ensure that data life cycle issues are taken into account. The data life cycle end-to-end in this situation would be data provisioning, data processing, data in transit, data at rest, and deprovisioning.

Let’s look at an example. Suppose an information security officer (ISO) asks a security team to randomly retrieve discarded computers from the warehouse trash bin. The security team retrieves two older computers and a broken multifunction network printer. The security team connects the hard drives from the two computers and the network printer to a computer equipped with forensic tools. They retrieve PDF files from the network printer hard drive but are unable to access the data on the two older hard drives. As a result of this finding, the warehouse management should update the hardware decommissioning procedures to remediate the security issue.

Let’s look at another example. Say that a new vendor product has been acquired to replace a legacy product. Significant time constraints exist due to the existing solution nearing end-of-life with no options for extended support. For this project, it has been emphasized that only essential activities be performed. To balance the security posture and the time constraints, you should test the new solution, migrate to the new solution, and decommission the old solution.

Introduction of functionality, an application, or a system can affect an organization’s security policy. For example, an organization may have a policy in place that prevents the use of any wireless technology at the enterprise level. If a new device or technology requires wireless access, the organization will need to revisit the security policy to allow wireless access. However, the organization must ensure that the appropriate security controls are implemented when wireless access is added to the enterprise. Performing a security impact analysis involves examining the impact of the new functionality, application, or system on the organization’s confidentiality, integrity, and availability. Threats, vulnerabilities, and risks are covered in greater detail in Chapter 3, “Risk Mitigation Strategies and Controls.”

Finally, as mentioned many other times throughout this book, security awareness and training are vital to ensure that day-to-day operational activities are carried out in a secure manner. Security awareness and training should be updated as new issues arise. Employees should attend this training at initial employment and at least once a year thereafter.

Instituting a formal change management process ensures that all changes are both approved and documented. Because any changes can affect both security and performance, special attention should be given to monitoring the solution after any changes.

Finally, vulnerability assessments and penetration testing after the solution is implemented can help discover any security or performance problems that might either be introduced by a change or arise as a result of a new threat.

Updating hardware and software can often have unanticipated consequences. A new application update may cause false positives on the enterprise firewall because the application communicates in a new manner. Simply ignoring a false positive (or disabling the alert) is not adequate. Security practitioners should research issues such as this to determine the best way to address the problem.

Another consequence could be that an update causes issues that cannot be resolved at the time of deployment. In such a case, it may be necessary to temporarily roll back the hardware or software to its previous state. However, it is important that the update not be forgotten. A plan should be implemented to ensure that the update is applied as quickly as possible. It may be necessary to allocate personnel to ensure that the issue is researched so that the update can be redeployed.

Let’s look at a maintenance example and its effects on security. Say that after a system update causes significant downtime, the chief information security officer (CISO) asks the IT manager who was responsible for the update. The IT manager responds that five different people have administrative access to the system, so it is impossible to determine the responsible party. To increase accountability in order to prevent this situation from reoccurring, the IT manager should implement an enforceable change management system and enable user-level auditing on all servers.

Any maintenance program should include documenting all maintenance activities, including the personnel who completed the maintenance, the type of maintenance that occurred, the result of the maintenance, and any issues that arose, along with the issue resolution notes. This documentation will provide guidance in the future.

Companies and their processes also evolve and change, which is a good thing. But change should be managed in a structured way so as to maintain a common sense of purpose about the changes. By following recommended steps in a formal process, change can be prevented from becoming a problem. For guidelines to include as a part of any change control policy, see Chapter 5, “Network and Security Components, Concepts, and Architectures.”

For the CASP exam, you need to keep in mind that change management works with configuration management to ensure that changes to assets do not unintentionally diminish security. Because of this, all changes must be documented, and all network diagrams, both logical and physical, must be updated constantly and consistently to accurately reflect each asset’s configuration now and not as it was two years ago. Verifying that all change management policies are being followed should be an ongoing process.

Let’s look at an example. Suppose that a company deploys more than 15,000 client computers and 1,500 server computers. The security administrator is receiving numerous alerts from the IDS of a possible infection spreading through the network via the Windows file sharing service. The security engineer believes that the best course of action is to block the file sharing service across the organization by placing access control lists (ACLs) on the internal routers. The organization should call an emergency change management meeting to ensure that the ACLs will not impact core business functions.

In many cases, it is beneficial to form a change control board. The tasks of the change control board can include:

• Ensuring that changes made are approved, tested, documented, and implemented correctly

• Meeting periodically to discuss change status accounting reports

• Maintaining responsibility for ensuring that changes made do not jeopardize the soundness of the verification system

Although it’s really a subset of change management, configuration management specifically focuses on bringing order out of the chaos that can occur when multiple engineers and technicians have administrative access to the computers and devices that make the network function. It follows the same basic change management process discussed in Chapter 5 but perhaps takes on even greater importance, considering the impact that conflicting changes can have (in some cases immediately) on the network.

Configuration management includes the following functions:

• Report the status of change processing.

• Document the functional and physical characteristics of each configuration item.

• Perform information capture and version control.

• Control changes to the configuration items and issue versions of configuration items from the software library.

The biggest contribution of configuration management controls is ensuring that changes to the system do not unintentionally diminish security.

Functional hard drives should be overwritten three times prior to disposal or reuse, according to Department of Defense (DoD) Instruction 5220.22. Modern hard disks can defy conventional forensic recovery after a single wiping pass, based on NIST Special Publication (SP) 800-88.

Keep in mind that encrypting the data on a hard drive will make the data irretrievable without the encryption key, provided that the encryption method used has not been broken. For all media types, this is the best method for protecting data.

For example, suppose a company plans to donate 1,000 used computers to a local school. The company has a large research and development department, and some of the computers were previously used to store proprietary research data. The security administrator should be concerned about data remnants on the donated machines. If the company does not have a device sanitization section in its data handling policy, the best course of action for the security administrator to take would be to delay the donation until all storage media on the computers can be sanitized.

An organization should also ensure that an asset is disposed of in a responsible manner that complies with local, state, and federal laws and regulations.

The following sections flesh out the software development life cycle steps in detail:

Step 1. Plan/initiate project

Step 2. Gather requirements

Step 3. Design

Step 4. Develop

Step 5. Test/validate

Step 6. Release/maintain

Step 7. Certify/accredit

Step 8. Change management and configuration management/replacement

Any information that is handled by the application needs a value assigned by its owner, and any special regulatory or compliance requirements need to be documented. For example, healthcare information is regulated by several federal laws and must be protected. The classification of all input and output data of the application needs to be documented, and the appropriate application controls should be documented to ensure that the input and output data are protected.

Data transmission must also be analyzed to determine the types of networks used. All data sources must be analyzed as well. Finally, the effect of the application on organizational operations and culture needs to be analyzed.

From a security perspective, an organization must identify potential vulnerabilities and threats. When this assessment is performed, the intended purpose of the software and the expected environment must be considered. Moreover, the sensitivity of the data that will be generated or handled by the solution must be assessed. Assigning a privacy impact rating to the data to help guide measures intended to protect the data from exposure might be useful.

During this process, the state of the application is determined in every phase of its activities. The state of the application refers to its functional and security posture during each operation it performs. Therefore, all possible operations must be identified to ensure that the software never enters an insecure state or acts in an unpredictable way.

Identifying the attack surface is also a part of this analysis. The attack surface describes what is available to be leveraged by an attacker. The amount of attack surface might change at various states of the application, but at no time should the attack surface provided violate the security needs identified in the gather requirements stage.

Many security issues with software are created through insecure coding practices, such as lack of input validation or data type checks. Security professionals must identify these issues in a code review that attempts to assume all possible attack scenarios and their impacts on the code. Not identifying these issues can lead to attacks such as buffer overflows and injection and to other error conditions.

• Verification testing: Determines whether the original design specifications have been met

• Validation testing: Takes a higher-level view and determines whether the original purpose of the software has been achieved

In many cases vulnerabilities are discovered in the live environments for which no current fix or patch exists. This is referred to as a zero-day vulnerability. Ideally, the supporting development staff should discover such vulnerabilities before those looking to exploit them do.

While certification and accreditation are related, they are not considered to be two steps in a process.

The purpose of this process is to ensure that all changes to the configuration of and to the source code itself are approved by the proper personnel and are implemented in a safe and logical manner. This process should always ensure continued functionality in the live environment, and changes should be documented fully, including all changes to hardware and software.

In some cases, it may be necessary to completely replace applications or systems. While some failures may be fixed with enhancements or changes, a failure may occur that can only be solved by completely replacing the application.

• Integrate risk analysis and mitigation in the software development life cycle.

• Use qualitative, quantitative, and hybrid risk analysis approaches based on standardized risk analysis methods.

• Track and manage weaknesses that are discovered throughout risk assessment, change management, and continuous monitoring.

Because software often contains vulnerabilities that are not discovered until the software is operational, security professionals should ensure that a patch management process is documented and implemented when necessary to provide risk mitigation. This includes using a change control process, testing any patches, keeping a working backup, scheduling production downtime, and establishing a back-out plan. Prior to deploying any patches, help desk personnel and key user groups should be notified. When patches are deployed, the least critical computers and devices should receive the patches first, moving up through the hierarchy until the most critical computers and devices are patched.

Once mitigations are deployed, the mitigations must be tested and verified, usually as part of quality assurance and testing. Any risk mitigation that has been completed must be verified by an independent party that is not the developer or system owner. Developers should be encouraged to use code signing to ensure code integrity, to determine who developed code, and to determine the purpose of the code. Code-signing certificates are digital certificates which ensure that code has not been changed. By signing code, organizations can determine if the code has been modified by an entity other than the signer. Code signing primarily covers running code, not stored code. While code signing verifies code integrity, it cannot guarantee freedom from security vulnerabilities or that an app will not load unsafe or unaltered code during execution.

The process of acquiring software has the following four phases:

1. Planning: During this phase, the organization performs a needs assessment, develops the software requirements, creates the acquisition strategy, and develops evaluation criteria and plan.

2. Contracting: Once planning is completed, the organization creates an RFP or other supplier solicitation forms, evaluates the supplier proposals, and negotiates the final contract with the selected seller.

3. Monitoring and accepting: After a contract is in place, the organization establishes the contract work schedule, implements change control procedures, and reviews and accepts the software deliverables.

4. Follow-on: When the software is in place, the organization must sustain the software, including managing risks and changes. At some point, it may be necessary for the organization to decommission the software.

Security professionals should be involved in the software assurance process. This process ensures that unintentional errors, malicious code, information theft, and unauthorized product changes or inserted agents are detected.

• Input validation

• Secure logging

• Encryption and decryption

WASC continually monitors attacks and has developed a list of top attack methods in use. This list can aid in ensuring that an organization is aware of the latest attack methods and how widespread they are. It can also assist an organization in making the proper changes to its web applications to mitigate these attack types.

• How to sign SOAP messages to ensure integrity (and also nonrepudiation)

• How to encrypt SOAP messages to ensure confidentiality

• How to attach security tokens to ascertain the sender’s identity

• Request elevated privileges unless absolutely necessary.

• Relax permissions on portions of its app bundle.

• Make unnecessary network connections.

• Listen for connections on unnecessary network ports.

• Listen for connections on public network interfaces inadvertently.

• Read or write files in publicly writable folders unless directed to do so by the user.

Moreover, the following code-hardening techniques should be followed:

• Add code that validates inputs to prevent integer overflows.

• Replace any unsafe string function calls with calls that are buffer-size-aware to prevent buffer overflows.

• Avoid passing data to interpreters whenever possible. When the use of interpreters is unavoidable, pass data to the interpreters in a safe fashion.

• To prevent command injection attacks in SQL queries, use parameterized application programming interfaces (APIs) (or manually quote the strings if parameterized APIs are unavailable).

• Avoid using the POSIX system function.

• Set reasonable values for environment variables (PATH, USER, and so on) and do not make security decisions based on their values.

• Fix bugs that cause race conditions which can lead to incorrect behavior (or worse).

• NX (no-execute) bit: Technology used in CPUs to segregate areas of memory for use by either storage of processor instructions (code) or storage of data.

• XN (never execute) bit: Method for specifying areas of memory that cannot be used for execution.

When they are available in the architecture of the system, these bits can be used to protect sensitive information from memory attacks. By utilizing the ability of the NX bit to segregate memory into areas where storage of processor instructions (code) and storage of data are kept separate, many attacks can be prevented. Also, the ability of the XN bit to mark certain areas of memory that are off-limits to execution of code can prevent other memory attacks as well.

The support for ASLR varies by operating system. The following systems offer some level of support for ASLR:

• Android 7.0

• DragonFly BSD

• Apple iOS 4.3 and above

• Microsoft Windows 7 and later

• NetBSD 5.0

• OpenBSD

• OS X (10.5 and above)

• Solaris 11.1

• Documented: The code is self-explaining, using comments to explain its role and functions

• Maintainable: The code isn’t overcomplicated, so anyone working with it need not understand the whole context of the code in order to make any changes.

• Efficiency: The code doesn’t use unnecessary resources to perform a desired action.

• Clarity: The code is easy to read and to understand.

• Refactored: Formatting is consistent and follows the language’s coding conventions.

• Well-tested: Critical bugs are identified in testing and eliminated to ensure that the software works the way it’s intended to work.

• Extensible: The code will be of use for some time.

When code is of good quality, it is much less likely to be compromised and will be more likely to be resistant to attacks.

Two types of fuzzing can be used to identify susceptibility to a fault injection attack:

• Mutation fuzzing: This type involves changing the existing input values (blindly).

• Generation-based fuzzing: This type involves generating the inputs from scratch, based on the specification/format.

To prevent fault injection attacks:

• Implement fuzz testing to help identify problems.

• Adhere to safe coding and project management practices.

• Deploy application-level firewalls.

Fuzzers are software tools that find and exploit weaknesses in web applications, using a process called fuzzing. They operate by injecting semi-random data into the program stack and then detecting bugs that result. They are easy to use, but one of the limitations is that they tend to find simpler bugs rather than some of the more complex ones. OWASP, an organization that focuses on improving software security, recommends several specific tools, including JBroFuzz and WSFuzzer. HTTP-based SOAP services are the main target of WSFuzzer.

A scenario in which a fuzzer would be used is during the development of a web application that will handle sensitive data. The fuzzer would help you determine whether the application is properly handling error exceptions. For example, say that you have a web application that is still undergoing testing, and you notice that when you mistype your credentials in the login screen of the application, the program crashes, and you are presented with a command prompt. If you wanted to reproduce the issue for study, you could run an online fuzzer against the login screen.

Figure 18-2 shows the output of a fuzzer called Peach. It is fuzzing the application with a mutator called StringMutator that continually alters the input. You can see in this output that some input to the tool has caused a crash. Peach has verified the fault by reproducing it. It sends more detail to a log that you can read to understand exactly what string value caused the crash.

The Microsoft SDL File/Regex Fuzzer is actually composed of two tools. One is File Fuzzer, which generates random content in files, and the other is Regex Fuzzer, which tests functions that use regular expressions. These tools are no longer available, but Microsoft has a new cloud-based fuzzing service. Microsoft’s Security Risk Detection (MSRD) tool uses artificial intelligence to automate the reasoning process that security experts use to find bugs and augments this process with cloud-based scaling. Figure 18-3 shows Regex Fuzzer walking the user through the fuzzing process. As you can see in this figure, in step 1 you enter the expression pattern to be tested and then proceed through the other steps.

• Formal review: This is an extremely thorough, line-by-line inspection, usually performed by multiple participants using multiple phases. This is the most time-consuming type of code review but the most effective at finding defects.

• Lightweight review: This type of code review is much more cursory than a formal review. It is usually done as a normal part of the development process. It can happen in several forms:

  • Pair programming: Two coders work side-by-side, checking one another’s work as they go.

  • Email: Code is emailed around to colleagues for them to review when time permits.

  • Over-the-shoulder: Coworkers review the code, and the author explains his or her reasoning.

  • Tool-assisted: Using automated testing tools is perhaps the most efficient method.

While code review is most typically performed on in-house applications, it may be warranted in other scenarios as well. For example, say that you are contracting with a third party to develop a web application to process credit cards. Considering the sensitive nature of the application, it would not be unusual for you to request your own code review to assess the security of the product.

In many cases, more than one tool should be used in testing an application. For example, an online banking application that has had its source code updated should undergo both penetration testing with accounts of varying privilege levels and a code review of the critical models to ensure that defects do not exist.

• Synthetic transaction monitoring, which is a type of proactive monitoring, is often preferred for websites and applications. It provides insight into the application’s availability and performance, warning of any potential issue before users experience any degradation in application behavior. It uses external agents to run scripted transactions against an application. For example, Microsoft’s System Center Operations Manager uses synthetic transactions to monitor databases, websites, and TCP port usage.

• In contrast, real user monitoring (RUM), which is a type of passive monitoring, is a monitoring method that captures and analyzes every transaction of every application or website user. Unlike synthetic monitoring, which attempts to gain performance insights by regularly testing synthetic interactions, RUM cuts through the guesswork by seeing exactly how your users are interacting with the application.

• Required fields must be populated.

• Fields with a defined data type can only accept data that is the required data type.

• Fields with character limits only allow the configured number of characters.

• Fields with a defined data range only accept data within that range.

• Fields only accept valid data.

Test coverage analysis creates additional test cases to increase coverage. It helps developers find areas of an application not exercised by a set of test cases. It helps in determining a quantitative measure of code coverage, which indirectly measures the quality of the application or product.

One disadvantage of code coverage measurement is that it measures coverage of what the code covers but cannot test what the code does not cover or what has not been written. In addition, this analysis looks at a structure or function that is already there rather than at those that do not yet exist.

GUI testing involves testing a product’s GUI to ensure that it meets its specifications through the use of test cases. API testing involves testing APIs directly in isolation and as part of the end-to-end transactions exercised during integration testing to determine whether the APIs return the correct responses.

The following sections discuss these software development methods:

• Build and fix

• Waterfall

• V-shaped

• Prototyping

• Incremental

• Spiral

• Rapid application development (RAD)

• Agile

• Joint analysis (or application) development (JAD)

• Cleanroom

Simply put, build and fix involves developing software as quickly as possible and releasing it. No formal control mechanisms are used to provide feedback during the process. The product is rushed to market, and problems are fixed on an as-discovered basis with patches and service packs. Although this approach gets the product to market faster and more cheaply, in the long run, the costs involved in addressing problems and the psychological damage to the product in the marketplace outweigh any initial cost savings.

Despite the fact that this model is still in use today, most successful developers have learned to implement one of the other models discussed in this section so that the initial product, while not necessarily perfect, comes much closer to meeting all the functional and security requirements of the design. Moreover, using these models helps in identifying and eliminating as many bugs as possible without relying on the customer for quality control.

In this simplistic model of the software development process, certain unrealistic assumptions are made, including the following:

• Each step can be completed and finalized without any effect from the later stages that might require rework.

• Iteration (reworking and repeating) among the steps in the process, which is typically called for in other models, is not stressed in this model.

• Phases are not seen as individual milestones, as they are in some other models discussed here.

The modified Waterfall method views each phase in the process as its own milestone in the project management process. Unlimited backward iteration (returning to earlier stages to address problems) is not allowed in this model. However, product verification and validation are performed in this model. Problems that are discovered during the project do not initiate a return to earlier stages but rather are dealt with after the project is complete.

The spiral model assumes that knowledge gained at each iteration is incorporated into the design as it evolves. In some cases, it even involves the customer making comments and observations at each iteration as well. Figure 18-7 shows this process. The radial dimension of the diagram represents cumulative cost, and the angular dimension represents progress made in completing each cycle.

Agile attempts to be nimble enough to react to situations that arise during development. Less time is spent on upfront analysis, and more emphasis is placed on learning from the process and incorporating lessons learned in real time. There is also more interaction with the customer throughout the process. Figure 18-9 compares the Waterfall model and the Agile model.

This often led to delays, finger-pointing, and multiple iterations through the linear cycle due to an overall lack of cooperation between the units.

DevOps aims at shorter development cycles, increased deployment frequency, and more dependable releases, in close alignment with business objectives. It encourages the three units to work together through all phases of the development process. Figure 18-11 shows a common symbol that represents this idea.

With the Agile software development methodology, the highest priority is to satisfy the customer. Requirements for the software change often. New deliveries occur at short intervals. Developers are trusted to do their jobs. A working application is the primary measure of success.

Agile development is subject to some risks:

• Security testing may be inadequate.

• New requirements may not be assessed for their security impact.

• Security issues may be ignored, particularly if they would cause schedule delays.

• Security often falls by the wayside.

• Software that functions correctly may not necessarily be secure.

To address these issues, organizations should include a security architect as part of the development team. Security awareness training should be mandatory for all team members. Security standards and best practices should be documented and followed by the entire team. Security testing tools should be used to test each development piece.

• Requirements and analysis

• Design

• Coding

• System integration

• Testing and debugging

• Delivery

• Maintenance

With the Waterfall software development methodology, the development stages are not revisited, projects take longer, and testing is harder because larger pieces are released. Often risks are ignored because they can negatively impact the project. This software development method involves the following risks:

• Developers cannot return to the design stage if a security issue is discovered.

• Developers may end up with software that is no longer needed or that doesn’t address current security issues.

• Security issues are more likely to be overlooked due to time constraints.

• Planning

• Risk analysis

• Engineering

• Coding and implementation

• Evaluation

With the spiral software development methodology, requirements are captured quickly and can be changed easily. But if the initial risk analysis is inadequate, the end project will have issues. Involving a risk analysis expert as part of the team can help ensure that the security is adequately assessed and designed.

Agile and spiral are usually considered better methods than the Waterfall method, especially considering how quickly the security landscape can change. However, each organization needs to decide which method best works for its particular situation.

A sequence-based versioning numbering system uses a hierarchy to indicate major and minor revisions. An example of this type of numbering is shown in Figure 18-12. Major revision might be represented as a change from 1.1 to 1.2, while minor ones might be represented as 1.1 to 1.12.

Other systems may be based on alphanumeric codes or date of release.

• The CERT C Secure Coding Standard

• The CERT C++ Secure Coding Standard

• The CERT Perl Secure Coding Standard

• SEI CERT C Coding Standard

• SEI CERT Oracle Coding Standard for Java

• Android TM Secure Coding Standard

• SEI CERT Perl Coding Standard

An SRTM would help to determine whether an appropriate level of assurance to the security requirements specified at project origin are carried through to implementation.

Let’s look at an example. Suppose a team of security engineers applies regulatory and corporate guidance to the design of a corporate network. The engineers generate an SRTM based on their work and a thorough analysis of the complete set of functional and performance requirements in the network specification. The purpose of an SRTM in this scenario is to allow certifiers to verify that the network meets applicable security requirements.

• Data design: This type of design describes the choice of data structures and the attributes and relationships between data objects that drove the selection.

• Architecture design: This type of design uses data flow diagrams and transformation mapping to describe distinct boundaries between incoming and outgoing data. It uses information flow characteristics and maps them into the program structure.

• Interface design: This type of design describes all interfaces, including internal and external program interfaces, as well as the design of the human interface.

• Procedural design: This type of design represents procedural detail and structured programming concepts, using graphical, tabular, and textual notations. It provides a blueprint for implementation and forms the basis for all subsequent software engineering work.

• Master test plan: This is a single high-level test plan for a project/product that unifies all other test plans.

• Testing level–specific test plan: This type of plan describes a test process at a lower level of testing, such as:

  • Unit test plan

  • Integration test plan

  • System test plan

  • Acceptance test plan

• Testing type–specific test plan: This type of plan is for a specific issue, such as performance tests and security tests.

It might be beneficial to create a test template to ensure that all required operations are carried out and all relevant testing data is collected. Such a template might include the following sections (based on the IEEE template for testing documentation):

• Test plan identifier: Provide a unique identifier for the document. (Adhere to the configuration management system if you have one.)

• Introduction:

  • Provide an overview of the test plan.

  • Specify the goals/objectives.

  • Specify any constraints.

• References: List the related documents, with links to them, if available, including the following:

  • Project plan

  • Configuration management plan

• Test items: List the test items (software/products) and their versions.

  Features to be tested:

  • List the features of the software/product to be tested.

  • Provide references to the requirements and/or design specifications of the features to be tested.

    Features not to be tested:

  • List the features of the software/product that will not be tested.

  • Specify the reasons these features won’t be tested.

• Approach:

  • Mention the overall approach to testing.

  • Specify the testing levels (if it’s a master test plan), the testing types, and the testing methods (manual/automated; white box/black box/gray box).

• Item pass/fail criteria: Specify the criteria that will be used to determine whether each test item (software/product) has passed or failed testing.

• Suspension criteria and resumption requirements:

  • Specify criteria to be used to suspend the testing activity.

  • Specify testing activities that must be redone when testing is resumed.

• Test deliverables: List test deliverables and links to them, if available, including the following:

  • Test plan (this document itself)

  • Test cases

  • Test scripts

  • Defect/enhancement logs

  • Test reports

• Test Environment:

  • Specify the properties of the test environment (hardware, software, network, and so on).

  • List any testing or related tools.

• Estimate: Provide a summary of test estimates (cost or effort) and/or provide a link to the detailed estimation.

• Schedule: Provide a summary of the schedule, specifying key test milestones, and/or provide a link to the detailed schedule.

• Staffing and training needs:

  • Specify staffing needs by role and required skills.

  • Identify training that is necessary to provide those skills, if not already acquired.

• Responsibilities: List the responsibilities of each team/role/individual.

• Risks:

  • List the risks that have been identified.

  • Specify the mitigation plan and the contingency plan for each risk.

• Assumptions and dependencies:

  • List the assumptions that have been made during the preparation of this plan.

  • List the dependencies.

• Approvals:

  • Specify the names and roles of all persons who must approve the plan.

  • Provide space for signatures and dates (if the document is to be printed).

Validation testing should be completed before a system is formally presented to the client. Once validation testing has been completed, acceptance testing should be completed with a subset of the users.

Validation testing and acceptance testing should not just be carried out for systems. As a security practitioner, you need to make sure that validation testing and acceptance testing are carried out for any security controls that are implemented in your enterprise. If you implement a new security control that does not fully protect against a documented security issue, there could be repercussions for your organization. If you implement a security control that causes problems, delays, or any other user acceptance issues, employee morale will suffer. Finding a balance between the two is critical.

The following should be characteristics of the unit testing:

• The test data is part of the specifications.

• Testing should check for out-of-range values and out-of-bounds conditions.

• Correct test output results should be developed and known beforehand.

Live or actual field data is not recommended for use in the unit testing procedures.

Additional testing is recommended, including the following:

• Integration testing: This type of testing assesses the way in which the modules work together and determines whether functional and security specifications have been met. The advantages to this testing include:

  • It provides a systematic technique for assembling system while uncovering errors.

  • It confirms assumptions which were made during unit testing

  • It can begin as soon as the relevant modules are available.

  • It verifies whether the software modules work in unity.

    Disadvantages include:

  • Locating faults is difficult.

  • Some interface links to be tested could be missed.

  • It can commence only after all the modules are designed.

  • High-risk critical modules are not isolated and tested on priority.

• User acceptance testing: This type of testing ensures that the customer (either internal or external) is satisfied with the functionality of the software. The advantages to this testing include:

  • The satisfaction of the client is increased.

  • The criteria for quality are set early.

  • Improved communication between team and customer.

    The only disadvantage is that it adds cost to the process.

• Regression testing: This type of testing takes places after changes are made to the code to ensure that the changes have reduced neither functionality nor security. Its advantages include the following:

  • Better integration of changes

  • Improved product quality

  • Detection of side effects

    The only disadvantage is the additional cost, but it is well worth it.

• Peer review: this type of testing, developers review one another’s code for security issues and code efficiency. The advantage is that it is more thorough than automated methods. The disadvantage is that it is time-consuming.

Figure 18-13 shows a popular vulnerability cycle taught in many security seminars that explains the order of vulnerability types that attackers run through over time.

Trends tend to work through this vulnerability cycle. A trending period where human interaction and social engineering are prevalent will soon be followed by a period where network attacks are prevalent. Once organizations adapt, attackers logically move to the next area in the cycle: services and servers. As time passes, organizations adapt, but so do the attackers. As a security professional, you must try to stay one step ahead of the attackers. Once you have implemented a new security control or solution, you cannot rest! You must then do your research, watch your enterprise, and discover the next threat or trend. One thing is for sure: A security practitioner with real skills and willingness to learn and adapt will always have job security!

Threat intelligence helps an organization understand new risks. Once new threats are more well understood, the organization will be better positioned to defend against them. Security professionals then will also be better prepared for those threats to which they are vulnerable.

While disruptive technologies are always forward looking and revolutionary, they are not always secure. In the rush to get a disruptive technology to market, security is not always the primary focus. For this reason, many organizations allow others to ride on the “bleeding edge” of the technology.

Some of the disruptive technologies on the horizon as we approach 2020 are:

• The four-year upgrade cycle will be a thing of the past. Yearly cycles for desktop updates will be the norm.

• Phishing attacks will victimize 1 out every 10 users, leading security professionals to focus their efforts in the following areas going forward:

  • Securing the perimeter

  • Encrypting at rest and in transit

• Bring your own device (BYOD) initiatives will drive solutions such as mobile device management (MDM).

• Usability issues caused by security measures will decline.

• We will see more movement to the cloud.

• Artificial intelligence and machine learning will be increasingly utilized to locate new clients and customers.

• 5G wireless promises to be at least 40 times faster and have at least 4 times as much coverage as 4G.

• A return to the zero-trust model: Organizations will move to a highly defensive posture in the face of ever-more-sophisticated attacks. Every privilege will be granted to a user only when absolutely required.

• Deception technology will rise in the fight to secure the Internet of things (IoT): This technology floods the network and makes it mathematically impossible for cybercriminals to gain access to a legitimate set of user identities. When one of these fake credentials is compromised and used, deception technology alerts IT.

• Behavioral analytics and artificial intelligence will be used in identity management: The system will learn user habits and be able to more easily identify activities that are abnormal.

• Robo hunters will be used as automated threat seekers: They can learn from what they discover and then take appropriate action (for example, by isolating a bad packet or compromised device).

• Blockchain will find increasing use: Blockchain allows a digital ledger of transactions to be created and shared among participants via a distributed network of computers. The blockchain ledger can detect suspicious online behavior and isolate the connection. This immutable ledger can also be presented in court and can prove that an unauthorized person extracted or copied a set of data.

For most organizations, object tracking and containment technologies are used only for inventory assets above a certain value. For example, most retail stores implement object containment technologies for high-priced electronics devices and jewelry. However, some organizations implement these technologies for all inventory, particularly in large warehouse environments.

Technologies used in this area include geotagging/geofencing and radio frequency identification (RFID).

Geofencing uses GPS to define geographic boundaries. A geofence is a virtual barrier, and alerts can occur when inventory enters or exits the boundary. Geofencing is used in retail management, transportation management, human resources management, law enforcement, and other areas.

Two types of RFID systems can be deployed: active reader/passive tag (ARPT) and active reader/active tag (ARAT). In an ARPT system, the active reader transmits signals and receives replies from passive tags. In an ARAT system, active tags are woken with signals from the active reader.

RFID chips can be read only if they are within a certain proximity of the RFID reader. A recent implementation of RFID chips is the Walt Disney Magic Band, which is issued to visitors at Disney resorts and theme parks. The band verifies park admission and allows visitors to reserve attraction and restaurant times and pay for purchases in the resort.

Different RFID systems are available for different wireless frequencies. If your organization decides to implement RFID, it is important that you fully research the advantages and disadvantages of different frequencies. However, that information is beyond the scope of the CASP exam.

Table 18-1 Key Topics for Chapter 18

Key Topic Element	Description	Page Number
List	The steps in the SDLC	665
List	Functions of configuration management	672
List	Disposal terms and concepts	673
List	Software development life cycle steps	674
List	Types of testing	676
List	Software acquisition phases	679
List	NX and XN bit use	682
List	Characteristics of high-quality code	683
List	Types of fuzzing	684
List	Types of code reviews	686
List	Approaches to dynamic testing	686
List	Software development methods	688
List	Contents of a system design document	701
List	Testing plans	702
List	Unit testing procedures	705
List	Disruptive technologies	708
List	Security trends	708

systems development life cycle (SDLC)

initiation stage

acquisition stage

implementation stage

disposal stage

test and evaluation phase

commissioning

decommissioning

baseline

change management

configuration management

configuration item (CI)

data purging

data remnant

data clearing

software development life cycle

plan/initiate phase

gather requirements phase

design phase

develop phase

test/validate phase

verification testing

validation testing

release/maintenance phase

certification

accreditation

application security frameworks

mitigation

acceptance testing

planning

contracting

monitoring and accepting

follow-on

standard libraries

Web Application Security Consortium (WASC)

Open Web Application Security Project (OWASP)

Build Security In (BSI) initiative

ISO/IEC 27000 series

Simple Object Access Protocol (SOAP)

Web Services Security (WS-Security, or WSS)

NX (no-execute) bit

XN (never execute) bit

address space layout randomization (ASLR)

code quality

code analyzer

fuzz testing

mutation fuzzing

generation-based fuzzing

static testing

formal review

lightweight review

pair programming

tool-assisted

dynamic testing

synthetic transaction monitoring

real user monitoring (RUM)

misuse case testing

test coverage analysis

Interface testing

build-and-fix approach

V-shaped model

prototyping

incremental model

spiral model

rapid application development (RAD)

Agile model

joint analysis (or application) development (JAD)

Cleanroom model

DevOps

continuous integration (CI)

versioning

security requirements traceability matrix (SRTM)

requirements definition

software design document (SDD)

data design

architecture design

interface design

procedural design

master test plan

validation testing

unit testing

integration testing

user acceptance testing

regression testing

peer review

vulnerability cycle

disruptive technologies

zero-trust model

robo hunter

asset management

inventory control

geotagging

geofencing

active reader/passive tag (ARPT)

active reader/active tag (ARAT)

operation/maintenance stage

1. Which of the following is a uniquely identifiable subset of the system that represents the smallest portion to be subject to an independent configuration control procedure?

• CI

• AV

• CU

• CC

2. You have been hired as a security analyst for your company. Recently, several assets have been marked to be removed from the enterprise. You need to document the steps that should be taken in relation to security. Which of the following guidelines should be implemented?

• Deploy the appropriate security controls on the asset.

• Deploy the most recent updates for the asset.

• Back up all the data on the asset and ensure that the data is completely removed.

• Shred all the hard drives in the asset.

3. Your organization has decided to formally adopt a change management process, and you have been asked to design the process. Which of the following guidelines should be part of this new process?

• Only critical changes should be fully analyzed.

• After formal approval, all costs and effects of implementation should be reviewed.

• Change steps should be developed only for complicated changes.

• All changes should be formally requested.

4. You have been asked to join the development team at your organization to provide guidance on security controls. During the first meeting, you discover that the development team does not fully understand the SDLC. During which phase of this life cycle is the system actually deployed?

• Acquire/develop

• Implement

• Initiate

• Operate/maintain

5. A development team has recently completed the deployment of a new learning management system (LMS) that will replace the current legacy system. The team successfully deploys the new LMS, and it is fully functional. Users are satisfied with the new system. What stage of the SDLC should you implement for the old system?

• Dispose

• Operate/maintain

• Initiate

• Acquire/develop

6. You have been asked to participate in the deployment of a new firewall. The project has just started and is still in the initiation stage. Which step should be completed as part of this stage?

• Develop security controls.

• Assess the system security.

• Ensure information preservation.

• Assess the business impact of the system.

7. You are working with a project team to deploy several new firewalls. The initiation stage is complete, and now the team is engaged in the acquisition stage. Which step should the team complete as part of this stage?

• Provide security categories for the new routers.

• Test the routers for security resiliency.

• Design the security architecture.

• Update the routers with the latest updates from the vendor.

8. What documents the security requirements that a new asset must meet?

• SDLC

• SRTM

• SSDLC

• RFID

9. Which of the following is a device-tracking technology?

• geolocation

• geotagging

• geofencing

• RFID

10. Which technology uses chips and receivers to manage inventory?

• geolocation

• geotagging

• SRTM

• RFID