Sharks in the Moat

by Phil Martin

  The production environment is where the live product lives and is off-limits to all but the deployment and maintenance teams. No one should be allowed to touch this environment unless they have a clear need to, and even then, separation of duties must be implemented.

  Testing for Code Security

  In the last section of this book, we will discuss supply chain management that controls how software moves from party to party. Each handoff point between parties is called a ‘provenance point’, and at each step of the supply chain where provenance points are encountered, we need to run a series of repeatable tests. Similar to regression testing, the tests should ideally be automated and provide a balance of being thorough while not taking too long to execute.

  There are other security testing tools that we can use as well to examine two attributes – existence and effectiveness. Good security testing not only checks for the existence of security controls, but also carries out tests to gauge how effective controls are in mitigating the associated vulnerability. Discovered weaknesses can often be automatically tracked down to the single line of source code that is at-fault using static source code analysis.

  Figure 126: Security Testing Tools

  Let’s walk through the most common types of tools used to test software, as shown in Figure 126.

  The first group, static tools, looks at the output of the development team in three states – the raw source code, bytecode, and binary code.

  Source code analyzers inspect the raw source code and look for syntactic and logical flow issues. This type of tool understands the specific language being used, including all common libraries in-use. This is essentially the last chance we have at detecting weaknesses during the development phase. The extent of source code analyzed is called code coverage and should be set to 100% by default. This setting can be tuned to decrease the execution time in the best static source code analyzers. Examples include bugScout, ClangStatic Analyzer, HP QAInspect, Rational AppScan Source Edition, Coverity SAVETM, FindSecurityBugs, FindBugs, Rough Auditing Tool for Security, Fortify Source Code Analyzer, CodeCenter, and CodeSecure.

  A static byte code scanner looks for vulnerabilities in the byte code. Remember that byte code is an intermediate version of the build process that can be executed by a run-time interpreter and can often reveal dependencies and weaknesses not visible in the raw source code. Examples include Moonwalker, FxCop, FindBugs, and Gendarme.

  A static binary code scanner looks at the final executable that will be run in the native environment and works by disassembling the code and looking for malicious or dangerous patterns. The great thing about this approach is that you don’t have to have the original source code available and is often the most useful when detecting issues in the supply chain. Additionally, a binary code scanner can detect any problems introduced by the compiler itself. Examples include VeraCode Security Review, IDA Pro, and Microsoft’s CAT.NET.

  While static tools look at source code or the output of the build process, dynamic scanners look at both the network and software application at run-time.

  In addition to probing weaknesses, a network scanner can audit system configuration and patching levels using fingerprinting and banner grabbing. Because it sniffs network traffic passing by, it can also detect vulnerable browsers, unpatched systems and even expired digital certificates. Examples include QualysGuard, Nessus, GFI LanGuard, Core Impact, and SAINT.

  A web application vulnerability scanner probes web apps to discover known weaknesses such as:

  Injection flaws

  Scripting issues

  Session mismanagement

  Cookie poisoning or theft

  Request forgeries

  Hidden form field manipulation

  Fail open authentication

  Information disclosure from error conditions

  Information disclosure from comments

  Examples include AppScan, Samurai Web Testing Framework, Burpsuite, w3af, Paros proxy, HP Webinspect, and Nikto.

  Malware detection and combat tools most commonly examine host systems and look for patterns that indicate the presence of malware. While detection will normally occur after infection, the tools do limit malware infiltration by early detection and alerting. Because malware authors are aware that scanners will most often use signature patterns to detect a threat, they code the malicious program to change its appearance, resulting in polymorphic malware. Some tools can detect a threat before it infects a system but this is a hit-or-miss proposition. Examples include Microsoft Baseline Security Analyzer, Microsoft Process Explorer, Trend Micro’s HiJackThis, Microsoft’s Malicious Software Removal tool, SUPER AntiSpyware, and Malwarebyte’s Anti-Malware.

  Finally, a security compliance validation tool focuses on how compliant an organization is to regulatory or internal policies. This is not an automated tool, but is most often implemented as a series of questionnaires for employees to fill out and submit. While normally geared to financial and health security breaches surrounding PFI and PHI, they can also be used with both PII and PCI DSS cardholder information.

  Chapter 42: The Project Role

  The Project role can be best illustrated by looking at the duties of a project manager. While some development methodologies such as Scrum minimize the need for a project manager in favor of a product owner, project management must always be performed by someone. In general, the Project role is responsible for linking the Product role with the Engineering Management, Architect and Development roles, with the primary communication vehicle being requirements documentation. The Project role touches literally every other role as well, and acts as the central management point for the entire project. Because the collection of proper requirements is one of the core responsibilities of any project manager, let’s discuss the process around that activity.

  Protection Needs Elicitation (PNE)

  While not specific to security requirements, PNE is one of the most crucial processes to ensure gaps do not appear in project requirements. When coupled with strong communication and collaboration with stakeholders, PNE will result in the best quality requirements, although the process can be challenging.

  Specific to security, PNE begins with the discovery of assets that need to be protected. The NSA has created something called the Information Assurance Technical Framework, or IATF, that includes PNE. IATF recommends that PNE be carried out by executing the following steps:

  Engage the customer.

  Model information management.

  Identify least privilege applications.

  Conduct threat modeling and analysis.

  Prioritize threats based on customer needs.

  Develop the information protection policy.

  Seek customer acceptance.

  Figure 127: PNE Techniques

  We’re going to go over the most common techniques to elicit requirements as shown in Figure 127.

  Brainstorming

  The goal of brainstorming is to gather and record as many ideas as possible. During this process, the merit of a suggestion is not debated, nor is it explored in a detailed fashion. The goal is simply to get the creative juices flowing and to capture the result. While this can quickly generate a lot of ideas, it is not recommended for PNE for a couple of reasons. First, it is probable that a large number of ideas do not relate to the business, technical or security context being explored. This can lead to gaps or to too much focus being applied to a non-trivial aspect of the software. Secondly, suggestions are usually not very comprehensive or consistent because the ideas are very subjective. It is acceptable to use brainstorming only if it is accompanied by one of the other techniques.

  Surveys

  While a survey can be a great tool to collect requirements, it is only as good as the questions are. Each survey must be customized to both the project and the audience. Both specific and open-ended questions should be used, as general questions can help to identify areas which the more specific questions might have missed. Questionnaires should tak
e into account three different areas – business risk, project risk and technology risk. It is helpful if the questions are written to cover both the software security profile and secure design principles. As examples, consider the following possible questions:

  What kind of data will be processed, transmitted or stored by the software?

  Is the data highly sensitive or confidential in nature?

  Will the software handle personally identifiable information or privacy related information?

  Who are all the users who will be allowed to make alterations, and will they need to be audited and monitored?

  What is the maximum tolerable downtime for the software?

  How quickly should the software be able to recover and restore normal operations when disrupted?

  Is there a need for single sign-on authentication?

  What are the roles of users that need to be established and what privileges and rights will each role have?

  What are the set of error messages and conditions that you would need the software to handle when an error occurs?

  Questionnaires can be collected through online sites or electronic documents, or perhaps as part of an interview with stakeholders. If the latter is chosen, be sure to identify a specific person who is responsible for recording the responses. If answers lead to new questions, then it is possible

  an additional PNE tactic will need to take place.

  Policy Decomposition

  A great source of security requirements are the various internal policies that an organization might have already accessible. However, because policies by definition contain high-level mandates, each will need to be broken down, or decomposed, into detailed security requirements. This process also can apply to external policies such as regulations and privacy and compliance mandates. To avoid confusion, for the remainder of this section we will refer to both internal and external sources as simply policy documents.

  Figure 128: The Policy Decomposition Process

  Because policies are high-level and open to interpretation, we have to be careful to consider the scope of each. This prevents us from injecting someone’s opinion as opposed to remaining objective. Figure 128 illustrates this process.

  In essence, decomposition breaks policy documents down into high-level objectives, which are then used to generate security requirements, which are finally used to create software security requirements. Let’s use an example to illustrate how this might happen.

  Let’s suppose we take the PCI DSS 6.3 requirements, which states:

  Develop software applications in accordance with PCI DSS and based on industry best practices incorporate information security throughout the software development life cycle.

  This is a fairly high-level statement and gives us a few things to chew on. For example, what does it look like to ‘incorporate information security throughout the SDLC’? What does ‘industry best practices’ mean to us? What industry are we in, and how does it impact that statement?

  We need to break this one statement down in high-level objectives. The results might look something like the following:

  CFG - Ensure proper configuration management

  SEG - Use segregated environments

  SOD - Ensure proper separation of duties

  DAT - Assure data protection

  PRC - Perform production readiness checks

  CRV - Execute code reviews

  We can then generate specific security requirements by decomposing each objective:

  CFG1 – Test all security patches, and system and software configuration changes before deployment

  SEG1 – Separate development/test and production environment

  SOD1 – Separation of duties between development/test and production environments.

  DAT1 – Ensure production data (live sensitive cardholder data) are not used for testing or development.

  PRC1 – Removal of test data and accounts before production systems become active.

  PRC2 – Removal of custom application accounts, user IDs, and passwords before applications become active or are released to customers.

  CRV1 - Review of custom code prior to release to production or customers in order to identify any potential coding vulnerability.

  Figure 129: Data Classification Labeling

  We can then generate software security requirements. For the CFG1 objective, we might come up with the following:

  CFG1.1 – Validate all input on both server and client end

  CFG1.2 – Handle all errors using try, catch and finally blocks

  CFG1.3 – Cryptographically protect data using 128-bit encryption of SHA-256 hashing when storing it

  CFG1.4 – Implement secure communications using Transport (TLS) or Network (IPSec) secure communications.

  CFG1.5 – Implement proper RBAC control mechanisms.

  Data Classification

  We have already discussed data classification when covering encryption technologies, but let’s dive in a little deeper. In its simplest terms, the goal for data classification is to protect data that needs to be protected without protecting data that does NOT need to be protected.

  Figure 129 provides a good example of how to label various data elements based on CIA attributes.

  Roles

  Now, who is supposed to do all of the classification work we have described to this point? The short answer is that the business owner has this responsibility and is often referred to as the data owner. This does not mean the data owner must implement the classification – that is often delegated to a data custodian. So where do the responsibilities for each role start and stop? The data owner should:

  Ensure that information assets are appropriately classified.

  Validate that security controls are implemented as needed by reviewing the classification periodically.

  Define authorized list of users and access criteria based on information classification. This supports the Separation of Duties principle of secure design.

  Ensure appropriate backup and recovery mechanisms are in place.

  Delegate as needed the classification responsibility, access approval authority, and backup and recovery duties to a data custodian.

  The data custodian should:

  Perform the information classification exercise.

  Perform backups and recovery as specified by the data owner.

  Ensure records retention is in place according to regulatory requirements or organizational retention policy.

  In summary, the data owner is ultimately accountable for all activities, but execution is often left to the data custodian.

  Data Lifecycle Management (DLM)

  Information lifecycle management, or ILM, deals with managing files based on both file attributes and file contents. A subset of ILM is Data Lifecycle Management, or DLM, which deals solely with file attributes and ignores file contents. In this section we are going to focus on DLM only.

  While there are many products out there that implement DLM, be sure to remember that DLM is a process, not a product. DLM protects data from creation to final disposition. Data classification is usually the first step in the DLM process, after which the appropriate CIA controls can be applied based on the classification. Some of the other things that DLM is concerned with are the following:

  Does the appropriate protection mechanism exist?

  What subjects have access to the data?

  What level of access does a subject have?

  Is the data stored as structured or unstructured?

  Is the environment in which the data is stored private, public or hybrid?

  DLM is concerned with data regardless of whether it is at-rest, in-transit or in-use, and ensures that the proper protection mechanisms are present. For example, when data is in-transit, DLM looks at the use of TLS, IPSec and DLP technologies. When data is at-rest, DLM ensures that proper encryption is being used and how data is stored in terms of availability. This last aspect – availability – is where Hierarchical Storage
Management, or HSM, solutions come into play. HSM allows different types of media to be used simultaneously to optimize retrieval times against cost. For example, an HSM might employ RAID systems, optical storage, tape, solid state drives and other technologies. In general, HSM can ensure that frequently accessed data is stored on media that is faster to respond, such as RAID systems, while data that is in an archived state can be stored on optical storage. If mobile media such as optical storage is to be used, then the security of this removable media must be taken into account, which DLM does. Data retention periods are also part of the DLM process. Because DLM must apply the proper level of access, retention and security, data classification is a crucial component.

  Subject/Object Matrix

  It is a rare well-formed system that does not require more than one role to control access. As a result, in most projects a subject/object matrix should be created so that access rules can be completely understood, and to prevent gaps in access rights from forming.

  A subject/object matrix is simply a 2-dimensional chart with roles (or subjects) along one axis and resources (or objects) along the other axis. The intersection between subject and object is populated with the proper level of access for that combination. We have previously discussed such an approach when covering threat modeling, although we used the term data access control matrix. They are one and the same.

  Figure 130: Example of Use & Misuse Cases