Domain 6: Security Assessment & Testing

Introduction

• Security assessment and testing are critical components of any information security program. Organizations must accurately assess their real-world security, focus on the most critical components, and make necessary changes to improve.
• In this domain, we will discuss two major components of assessment and testing: overall security assessments, including vulnerability scanning, penetration testing, and security audits; and testing software via static and dynamic methods.

Assessing access control

• A number of processes exist to assess the effectiveness of access control.
• Tests with a narrower scope include penetration tests, vulnerability assessments, and security audits.
• A security assessment is a broader test that may include narrower tests, such as penetration tests, as subsections.

Penetration testing

• A penetration tester is a white hat hacker who receives authorization to attempt to break into an organization’s physical or electronic perimeter (sometimes both).
• Pen tests are designed to determine whether black hat hackers could do the same. They are a narrow but often useful test, especially if the penetration tester is successful.
• Pen tests may include the following elements:
  • Network (Internet)
  • Network (internal or DMZ)
  • War dialling
  • Wireless
  • Physical (attempt to gain entrance into a facility or room)
• Network attacks may leverage client-side attacks, server-side attacks, or Web application attacks.
• War dialling uses a modem to dial a series of phone numbers, looking for an answering modem carrier tone. The pen tester then attempts to access the answering system.
• Social engineering is a no-tech or low-tech method that uses the human mind to bypass security controls. Social engineering may be used in combination with many types of attacks, especially client-side attacks or physical tests.
  • An example of a social engineering attack combined with a client-side attack is emailing malware with a subject line of “Category 5 Hurricane is about to hit Florida!”
• A zero-knowledge test, also called black-box test, is “blind”; the pen tester begins with no external or trusted information and begins the attack with public information only.
• A full-knowledge test (also called crystal-box test) provides internal information to the pen tester, including network diagrams, policies and procedures, and sometimes reports from previous pen testers.
• Partial-knowledge tests are in between zero and full knowledge; the pen tester receives some limited trusted information.

Pen testing tools & methodology

• Pen testers often use tools such as the open-source Metasploit and closed-source Core Impact & Immunity Canvas.
• They also use custom tools, as well as malware samples and code posted to the Internet.
• Pen testers use the following methodology:
  • Planning
  • Reconnaissance
  • Scanning (also called enumeration)
  • Vulnerability assessment
  • Exploitation
  • Reporting
• Black hat hackers typically follow a similar methodology although they may perform less planning, and obviously omit reporting. Black hats will also cover their tracks by erasing logs and other signs of intrusion, and they frequently violate system integrity by installing back doors in order to maintain access.
• A pen tester should always protect data and system integrity.

Assuring confidentiality, data integrity & system integrity

• Pen testers must ensure the confidentiality of any sensitive data that is accessed during the test.
• If the target of a pen test is a credit card database, the pen tester may have no legal right to view or download the credit card details. Testers will often request that a dummy file containing no regulated or sensitive data be placed in the same area of the system as the credit card data and protected with the same permissions. If the tester can read and/or write to that file, then they prove they could have done the same to the credit card data.
• Pen testers must ensure the system integrity and data integrity of their client’s systems. Any active attack, as opposed to a passive read-only attack, against a system could potentially cause damage; this can be true even for an experienced pen tester. This risk must be clearly understood by all parties, and tests are often performed during change maintenance windows for this reason.
• One potential issue that should be discussed before the pen test commences is the risk of encountering signs of a previous or current successful malicious attack.
  • Pen testers sometimes discover that they are not the first attacker to compromise a system and that someone has beaten them to it.
  • Attackers will often become more malicious if they believe they have been discovered, sometimes violating data and system integrity.
  • The integrity of the system is at risk in this case, and the pen tester should end the test and immediately escalate the issue.
• Finally, the final pen test report should be protected at a very high level, as it contains a roadmap to attack the organization.

Vulnerability testing

• Vulnerability scanning or vulnerability-testing scans a network or system for a list of predefined vulnerabilities such as system misconfiguration, outdated software, or a lack of patching.
• A vulnerability-testing tool such as Nessus or OpenVAS, or a cloud service such as Qualys, may be used to identify the vulnerabilities.

Security audits

• A security audit is a test against a published standard.
• Organizations may be audited for PCI DSS compliance, for example. PCI DSS includes many required controls, such as firewalls, specific access control models, and wireless encryption.
• An auditor then verifies that a site or organization meets the published standard.

Security assessments

• Security assessments are a holistic approach to assessing the effectiveness of access control.
• Instead of looking narrowly at pen tests or vulnerability assessments, security assessments have a broader scope.
• Security assessments view many controls across multiple domains and may include the following:
  • Policies, procedures, and other administrative controls
  • Assessing the real world-effectiveness of administrative controls
  • Change management
  • Architectural review
  • Pen tests
  • Vulnerability assessments
  • Security audits
• As the above list shows, a security assessment may include other distinct tests, such as a pen test. The goal is to broadly cover many other specific tests to ensure that all aspects of access control are considered.

Log reviews

• Reviewing security audit logs within an IT system is one of the easiest ways to verify that access control mechanisms are performing adequately.
• Reviewing audit logs is primarily a detective control.
• The intelligence gained from proactive audit log management and monitoring can be very beneficial; the collected antivirus logs of thousands of systems can give a very accurate picture of the current state of malware.
• Antivirus alerts combined with a spike in failed authentication alerts from authentication servers or a spike in outbound firewall denials may indicate that a password-guessing worm is attempting to spread across a network.

Software testing methods

• In addition to testing the features and stability of the software, testing increasingly focuses on discovering specific programmer errors leading to vulnerabilities that risk system compromise, including a lack of bounds checking.
• Two general approaches to automated code review exist: static and dynamic testing.

Static & dynamic testing

• Static testing tests the code passively; the code is not running.
  • This includes walkthroughs, syntax checking, and code reviews.
  • Static analysis tools review the raw source code itself looking for evidence of known insecure practices, functions, libraries, or other characteristics used in the source code.
  • The Unix lint program performs static testing for C programs.
• Dynamic testing tests the code while executing it.
  • With dynamic testing, security checks are performed while actually running or executing the code or application under review.
• Both approaches are valid and complement each other.
• Static analysis tools might uncover flaws in code that have not even yet been fully implemented in a way that would expose the flaw to dynamic testing.
• However, dynamic analysis might uncover flaws that exist in the particular implementation and interaction of code that static analysis missed.
• White-box software testing gives the tester access to program source code, data structures, variables, etc.
• Black-box testing gives the tester no internal details; the software is treated as a black box that receives inputs.

Traceability matrix

• A traceability matrix, sometimes called a requirements traceability matrix (RTM), can be used to map customers’ requirements to the software testing plan; it traces the requirements and ensures that they are being met. It does this by mapping customer usage to test cases.

Synthetic transactions

• Synthetic transactions, or synthetic monitoring, involve building scripts or tools that simulate activities normally performed in an application.
• The typical goal of using synthetic transactions/monitoring is to establish expected norms for the performance of these transactions.
• These synthetic transactions can be automated to run on a periodic basis to ensure the application is still performing as expected.
• These types of transactions can also be useful for testing application updates prior to deployment to ensure that functionality and performance will not be negatively impacted.
• This type of testing or monitoring is most commonly associated with custom-developed web applications.

Software testing levels

• It is usually helpful to approach the challenge of testing software from multiple angles, addressing various testing levels from low to high.
• The software testing levels designed to accomplish that goal are unit testing, installation testing, integration testing, regression testing, and acceptance testing.
  • Unit testing: Low-level tests of software components, such as functions, procedures, or objects.
  • Installation testing: Testing software as it is installed and first operated.
  • Integration testing: Testing multiple software components as they are combined into a working system. Subsets may be tested, or Big Bang integration testing is used for all integrated software components.
  • Regression testing: Testing software after updates, modifications, or patches.
  • Acceptance testing: Testing to ensure that the software meets the customer’s operational requirements. When this testing is done directly by the customer, it is called user acceptance testing.

Fuzzing

• Fuzzing (or fuzz testing) is a type of black-box testing that submits random, malformed data as inputs into software programs to determine if they will crash.
• A program that crashes when receiving malformed or unexpected input is likely to suffer from a boundary-checking issue and may be vulnerable to a buffer overflow attack.
• Fuzzing is typically automated (with tools such as zzuf), repeatedly presenting random input strings as command line switches, environment variables, and program inputs. Any program that crashes or hangs has failed the fuzz test.

Combinatorial software testing

• Combinatorial software testing is a black-box testing method that seeks to identify and test all unique combinations of software inputs.
• An example of combinatorial software testing is pairwise testing, also called all-pairs testing.

Misuse case testing

• Misuse case testing leverages use cases for applications, which spell out how various functionalities will be leveraged within an application.
• Formal use cases are typically built as a flow diagram written in UML (Unified Modeling Language) and are created to help model expected behavior and functionality.
• Misuse case testing models how a security impact could be realized by an adversary abusing the application.
• This can be seen simply as a different type of use case, but the reason for calling out misuse case testing specifically is to highlight the general lack of attacks against the application.

Test coverage analysis

• Test or code coverage analysis attempts to identify the degree to which code testing applies to the entire application.
• The goal is to ensure that there are no significant gaps where a lack of testing could allow for bugs or security issues to be present that otherwise should have been discovered.

Interface testing

• Interface testing is primarily concerned with appropriate functionality being exposed across all the ways users can interact with the application.
• From a security-oriented vantage point, the goal is to ensure that security is uniformly applied across the various interfaces.
• This type of testing exercises the various attack vectors an adversary could leverage.

Summary of exam objectives

• Vulnerability scanning determines one half of the Risk = Threat × Vulnerability equation.
• Pen tests seek to match those vulnerabilities with threats in order to demonstrate real-world risk.
• Assessments provide a broader view of the security picture, and audits demonstrate compliance with a published specification, such as PCI DSS.
• We discussed testing code security, including static methods such as source code analysis, walkthroughs, and syntax checking.
• We discussed dynamic methods used on running code, including fuzzing and various forms of black-box testing.
• We also discussed synthetic transactions, which attempt to emulate real-world use of an application through the use of scripts or tools that simulate activities normally performed in an application.