Today the software security testing is an indispensable part of building modern software industry. Organizations have invested in precious resources and scarce skills in various necessary security efforts. This article highlights the essentials of software security to bridge the gap in knowledge between vulnerability researchers and security testing experts.

Software security testing is an indispensable part of building modern software. Securing and operating today’s complex systems is challenging and demanding. Mission and operational requirements to deliver services and applications swiftly and securely have never been greater. Organizations, having invested precious resources and scarce skills in various necessary security efforts such as risk analysis, certification, accreditation, security architectures, policy development, and other security efforts, can be tempted to neglect or insufficiently develop a cohesive, well-though out operational security testing program.

Testing and Quality Assurance

Part of software testing involves replicating customer use cases against a given application. These use cases are documented in a test plan during the quality assurance phase in the development cycle to act as a checklist ensuring common use cases aren't missed during the testing phase. People within the quality assurance community are starting to understand that checking an application for security issues (vulnerabilities) isn't just the responsibility of the security department (if one exists), or the software architects. While typical QA (Quality Assurance) engineers don't understand the scope or inner working of specific software vulnerabilities, they do go about testing an application in a similar fashion to how the penetration testing community does. Unlike typical penetration testing QA has access to internal documents and insider information giving them advantages to aide in the testing of an application. In addition to documenting customer use cases it's important to begin the process of documenting what an attacker may attempt against your application as well and incorporating these attacker 'use cases' into a security section of your standard test plan.

Software Security Challenges

Software security is about making software behave in the presence of a malicious attack, even though in the real world, software failures usually happen spontaneously—that is, without intentional mischief. Not surprisingly, standard software testing literature is only concerned with what happens when software fails, regardless of intent. The difference between software safety and software security is therefore the presence of an intelligent adversary bent on breaking the system.

Security is always relative to the information and services being protected, the skills and resources of adversaries, and the costs of potential assurance remedies; security is an exercise in risk management. Risk analysis, especially at the design level, can help us identify potential security problems and their impact. Once identified and ranked, software risks can then help guide software security testing.

A vulnerability is an error that an attacker can exploit. Many types of vulnerabilities exist, and computer security researchers have created taxonomies of them. Security vulnerabilities in software systems range from local implementation errors (such as use of the gets() function call in C/C++), through inter-procedural interface errors (such as a race condition between an access control check and a file operation), to much higher design-level mistakes (such as error handling and recovery systems that fail in an insecure fashion or object-sharing systems that mistakenly include transitive trust issues). Vulnerabilities typically fall into two categories—bugs at the implementation level and flaws at the design level.

Attackers generally don’t care whether a vulnerability is due to a flaw or a bug, although bugs tend to be easier to exploit. Because attacks are now becoming more sophisticated, the notion of which vulnerabilities actually matter is changing. Although timing attacks, including the well-known race condition, were considered exotic just a few years ago, they’re common now. Similarly, two-stage buffer overflow attacks using trampolines were once the domain of software scientists, but now appear in 0 day exploits.

Design-level vulnerabilities are the hardest defect category to handle, but they’re also the most prevalent and critical. Unfortunately, ascertaining whether a program has design-level vulnerabilities requires great expertise, which makes finding such flaws not only difficult, but particularly hard to automate.

Examples of design-level problems include error handling in object-oriented systems, object sharing and trust issues, unprotected data channels (both internal and external), incorrect or missing access control mechanisms, lack of auditing/logging or incorrect logging, and ordering and timing errors (especially in multithreaded systems). These sorts of flaws almost always lead to security risk.

Risk Management and Security Testing

Software security practitioners perform many different tasks to manage software security risks, including

• creating security abuse/misuse cases;

• listing normative security requirements;

• performing architectural risk analysis;

• building risk-based security test plans;

• wielding static analysis tools;

• performing security tests;

• performing penetration testing in the final environment; and

• cleaning up after security breaches.

Figure 1 : The software development life cycle. Throughout this series, we’ll focus on specific parts of the cycle; here, we’re examining risk-based security testing.

Three of these are particularly closely linked—architectural risk analysis, risk-based security test planning, and security testing—because a critical aspect of security testing relies on probing security risks. Last issue’s installment1 explained how to approach a software security risk analysis, the end product being a set of security-related risks ranked by business or mission impact. (Figure 1 shows where we are in our series of articles about software security’s place in the software development life cycle.)

The pithy aphorism, “software security is not security software” provides an important motivator for security testing. Although security features such as cryptography, strong authentication, and access control play a critical role in software security, security itself is an emergent property of the entire system, not just the security mechanisms and features. A buffer overflow is a security problem regardless of whether it exists in a security feature or in the non-critical GUI. Thus, security testing must necessarily involve two diverse approaches:

1. testing security mechanisms to ensure that their functionality is properly implemented, and
2. performing risk-based security testing motivated by understanding and simulating the attacker’s approach.

Many developers erroneously believe that security involves only the addition and use of various security features, which leads to the incorrect belief that “adding SSL” is tantamount to securing an application. Software security practitioners bemoan the over-reliance on “magic crypto fairy dust” as a reaction to this problem. Software testers charged with security testing often fall prey to the same thinking.

How to approach security testing

Like any other form of testing, security testing involves determining who should do it and what activities they should undertake.

Who
Because security testing involves two approaches, the question of who should do it has two answers. Standard testing organizations using a traditional approach can perform functional security testing. For example, ensuring that access control mechanisms work as advertised is a classic functional testing exercise.

On the other hand, traditional QA staff will have more difficulty performing risk-based security testing. The problem is one of expertise. First, security tests (especially those resulting in complete exploit) are difficult to craft because the designer must think like an attacker. Second, security tests don’t often cause direct security exploit and thus present an observability problem. A security test could result in an unanticipated outcome that requires the tester to perform further sophisticated analysis. Bottom line: risk-based security testing relies more on expertise and experience than we would like.

How
Books like How to Break Software Security and Exploiting Software help educate testing professionals on how to think like an attacker. Nevertheless, software exploits are surprisingly sophisticated these days, and the level of discourse found in books and articles is only now coming into alignment.

White- and black-box testing and analysis methods both attempt to understand software, but they use different approaches depending on whether the analyst or tester has access to source code. White-box analysis involves analyzing and understanding source code and the design. It’s typically very effective in finding programming errors (bugs when automatically scanning code and flaws when doing risk analysis); in some cases, this approach amounts to pattern matching and can even be automated with a static analyzer (the subject of a future installment of this department). One drawback to this kind of testing is that it might report a potential vulnerability where none actually exists (a false positive). Nevertheless, using static analysis methods on source code is a good technique for analyzing certain kinds of software. Similarly, risk analysis is a whitebox approach based on a deep understanding of software architecture.

Black-box analysis refers to analyzing a running program by probing it with various inputs. This kind of testing requires only a running program and doesn’t use source-code analysis of any kind. In the security paradigm, malicious input can be supplied to the program in an effort to break it: if the program breaks during a particular test, then we might have discovered a security problem. Black-box testing is possible even without access to binary code—that is, a program can be tested remotely over a network. If the tester can supply the proper input (and observe the test’s effect), then black-box testing is possible.

Any testing method can reveal possible software risks and potential exploits. One problem with almost all kinds of security testing (regardless of whether it’s black or white box) is the lack of it—most QA organizations focus on features and spend very little time understanding or probing nonfunctional security risks. Exacerbating the problem, the QA process is often broken in many commercial software houses due to time and budget constraints and the belief that QA is not an essential part of software development.

Roles and Responsibilities

Because security testing provides input into and can be a part of multiple system development life cycle phases, a number of IT and system security staff may be interested in its execution and result. This section provides a list of those roles and identifies their responsibilities related to security testing. These roles may vary with the organization, however, and not all organizations will have the identical roles described here.

Senior IT Management/Chief Information Officer (CIO): The Senior IT Management/CIO ensures that the organization’s security posture is adequate. The Senior IT Management provides direction and advisory services for the protection of information systems for the entire organization. The Senior IT Management/CIO is responsible for the following activities that are associated with security testing:

• Coordinating the development and maintenance of the organization's information security policies, standards, and procedures,

• Ensuring the establishment of, and compliance with, consistent security evaluation processes throughout the organization, and

• Participating in developing processes for decision-making and prioritization of systems for security testing.

Information Systems Security Program Managers (ISSM): The Information Systems Security Program Managers (ISSMs) oversee the implementation of, and compliance with the standards, rules, and regulations specified in the organization's security policy. The ISSMs are responsible for the following activities associated with security testing:

• Developing and implementing standard operating procedures (security policy),

• Complying with security policies, standards and requirements, and

• Ensuring that critical systems are identified and scheduled for periodic testing according to the security policy requirements of each respective system.

Information Systems Security Officers (ISSO): The Information Systems Security Officers (ISSOs) are responsible for overseeing all aspects of information security within a specific organizational entity. They ensure that the organization's information security practices comply with organizational and departmental policies, standards, and procedures. ISSOs are responsible for the following activities associated with security testing:

• Developing security standards and procedures for their area of responsibility,

• Cooperating in the development and implementation of security tools and mechanisms,

• Maintaining configuration profiles of all systems controlled by the organization, including but not limited to, mainframes, distributed systems, microcomputers, and dial access ports, and

• Maintaining operational integrity of systems by conducting tests and ensuring that designated IT professionals are conducting scheduled testing on critical systems.

System and Network Administrators: System and network administrators must address the security requirements of the specific system(s) for which they are responsible on a daily basis. Security issues and solutions can originate from either outside (e.g., security patches and fixes from the vendor or computer security incident response teams) or within the organization (e.g., the Security Office). The administrators are responsible for the following activities associated with security testing:

• Monitoring system integrity, protection levels, and security related events,

• Resolving detected security anomalies associated with their information system resources,

• Conducting security tests as required, and

• Assessing and verifying the implemented security measures.

Managers and Owners: Managers and owners of a system oversee the overall compliance of their assets with their defined/identified security requirements. They are also responsible for ensuring that test results and recommendations are adopted as appropriate.

Post-Testing Actions

For most organizations, testing likely will reveal issues that need to be addressed quickly. How these issues are addressed and mitigated is the most important step in the testing process. The most common root causes and methods for addressing them are provided below.

Lack of (or Poorly Enforced) Organizational Security Policy: Perhaps the single largest contributor to poorly secured systems is the lack of an organizational security policy. A security policy is important as it ensures consistency. Consistency is a critical component of a successful security posture because it leads to predictable behavior. This will make it easier for an organization to maintain secure configurations and will assist in identifying security problems (which often manifest themselves as deviations from predictable, expected behavior). Each organization needs to have a security policy and to communicate that policy to users and administrators. A security policy should generally include:

• Organizational Standards (these usually specify uniform use of specific technologies, parameters and/or procedures)

• Privacy (e.g., whether there is monitoring of email and web use)

• Acceptable use guidelines (e.g., what is acceptable use of organization computing and network resources)

• Roles and responsibilities (for users, administrators, management)

• Accountability (auditing, incident handling)

• Authentication (e.g., passwords, biometrics)

• Availability of resources (redundancy, recovery, backups)

• Compliance (infractions, consequences and penalties).

Documenting Security Testing Results

Security testing provides insight into the other system development life cycle activities such as risk analysis and contingency planning. Security testing results should be documented and made available for staff involved in other IT and security related areas. Specifically, security testing results can be used in the following ways:

• As a reference point for corrective action,

• In defining mitigation activities to address identified vulnerabilities,

• As a benchmark for tracing an organization’s progress in meeting security requirements,

• To assess the implementation status of system security requirements,

• To conduct cost/benefit analysis for improvements to system security, and

• To enhance other life-cycle activities, such as risk assessments, Certification and Authorization (C&A), and performance improvement efforts.

Conclusion

There is no silver bullet for software security; even a reasonable security testing regimen is just a start. Unfortunately security continues to be sold as a product, and most defensive mechanisms on the market do little to address the heart of the problem, which is bad software. Instead, they operate in a reactive mode: don’t allow packets to this or that port, watch out for files that include this pattern in them, throw partial packets and oversized packets away without looking at them. Network traffic is not the best way to approach this predicament, because the software that processes the packets is the problem. By using a risk-based approach to software security testing, testing professionals can help solve security problems while software is still in production.

—By: R. Manoj. The author is an Assistant Editor at Fanatic Media, Bangalore. He is also an Independent Researcher, specializing in Software Security. He has an active interest in designing security algorithms for securing softwares. He can reached at infosecurity@fanaticmedia.com