Building Application Security Testing into the Software Development Life Cycle - APPLICATION DEVELOPMENT SECURITY - Information Security Management Handbook, Sixth Edition (2012)

Information Security Management Handbook, Sixth Edition (2012)

DOMAIN 4: APPLICATION DEVELOPMENT SECURITY

System Development Controls

Chapter 17. Building Application Security Testing into the Software Development Life Cycle

Sandy Bacik

Every enterprise should utilize an application development life cycle and within that life cycle there should be an application security architecture. An application security architecture contains a strong foundation of the application, providing controls to protect the confidentiality of information, integrity of data, and access to the data when it is required (availability) and ensuring it is the authorized entities. And an application security architecture carefully considers feature sets, controls, safer and reliable processes using the enterprise’s security posture. As security controls are developed for an application, they must be tested during the use test and quality assurance testing processes. At a very high level, application security testing should consider answering the following questions:

Is the process surrounding this function, service, or feature as safe and strong as possible without impacting operational requirements? In other words, is this a flawed process?

If I were a bad entity, how could/would I abuse this function, service, or feature?

If I were an inexperienced user, how could/would I use/abuse this function, service, or feature?

Is the function, service, or feature required to be on by default? If so, are there limits or options that could help limit the risk from this function, service, or feature?

Have success, failure, and abuse been considered when testing this function, service, or feature?

Security functions, services, and features that are built into an application should be based on existing application objectives, business requirements, use cases, and then test cases. When developing security functions, services, and features within an application that are based on documented requirements, the development of test cases for security should be relatively easy. Many times, this is not the case. The tester must then attempt to build security testing into the quality assurance testing processes. If it is the responsibility of the tester to include security testing into their process without the support of management and security being built into the life cycle, the job of the tester will be uphill in ensuring that security testing is included as part of the application life cycle. Building in security requirements and test cases will produce a stronger and more secure application and application development life cycle.

Over the last decade, many software issues have not improved. Some of the top software development flaws include the following, but this is not an exhaustive list:

Buffer overruns

Format string problems

Integer overflows

SQL and command injection

Failing to handle errors or revealing too much information

Cross-site scripting

Failing to protect network transactions

Use of magic URLs and hidden form fields

Improper use of SSL and TLS

Use of weak authentication mechanism, such as weak passwords

Failing to store and protect data securely

Information leakage

Improper file access

Race conditions

Poor usability

How can we improve this? Yes, extending the application development life cycle to include more testing, specifically security testing. Without a good foundation to develop security testing, improving the security of an application cannot be accomplished. Before developing application test cases and testing requirements, standard definitions need to be accepted by the group. For example,

A set of test requirements are technical or administrative actionable statements that are not subject to interpretation for a tester to develop a test plan/procedure.

A test case is a step scenario of the items to be tested based upon a set of use cases and requirements.

A test plan/procedure is a detailed list of tasks based on a requirement to perform the test. This would be the “how.” For example, a test plan/procedure will contain a requirement, passed, failed, and remarks about the test. A requirement would be something similar to “the time stamp shall be read from the clock off a centralized time source.”

A test program is a set or collection of test plans/procedures.

Defining a test requirement

– The term “shall” means the requirement is required.

– The term “should” means the requirement is optional.

– The requirement shall be positively stated.

– The requirement shall contain one and only one action.

– The requirement shall be documented as technical or administrative.

– The requirement shall be detailed enough to tell the tester what specifically needs to be tested and not contain implementation details.

– The requirement shall include what needs to be verified.

– The requirement shall use strong verbs. Action verbs are observable and better communicate the intent of what is to be attempted, like to plan, write, conduct, produce, apply, recite, revise, contrast, install, select, assemble, compare, investigate, develop, demonstrate, find, use, perform, show, assess, identify, illustrate, classify, formulate, indicate, represent, explain, etc.

– The requirement shall avoid using verbs that can be misinterpreted, such as understand, know, think, determine, believe, aware of, familiar with, conceptualize, learn, comprehend, appreciate, and are conscious of.

– The requirement shall avoid generalities in objective statements and infinitives to avoid include to know, understand, enjoy, and believe rather than to learn, understand, and feel. The words need to be not only active but also measurable.

Example of Integrating Security into the Application Development Life Cycle

As an example of integrating security into the application development life cycle and developing security application testing, while an application is being developed, use or business cases are developed to ensure that the application being developed meets the needs of the stakeholders. Then application use cases form the basis of developing test cases for quality assurance testers to test. The application use case can provide the following baselines for developing a test case and test requirements:

Name the system scope and boundaries.

Who are the primary actors or what are the endpoints sending and receiving information?

What is the goal of the system or transaction?

Who are the stakeholders?

What are the requirements?

What are actor/endpoint interests, preconditions, and guarantees?

What is the main success scenario?

What are the steps to success?

From the above information being described in an application use case, application security requirements can be developed. Therefore, if the application development requirements include something like the following, again, not an exhaustive list:

Data entry fields shall have secure defaults.

Access shall be based on the principle of least privilege.

The application shall employ a defense-in-depth strategy.

The application shall fail securely and not display sensitive information.

The application shall verify and validate all services.

The application shall employ segregation of duties based on roles.

From this list of requirements, we know that the following functions are the minimum that are required for this application:

Administration

Integration

Authentication

Authorization

Segregation of duties

Access control

Logging

Record/log retention

Reporting, alerting, and monitoring

As the scenarios are developed for test cases, the above functions need to be integrated into the scenarios and steps within the application. A sample test case paragraph could be as follows:

The application user shall be authenticated using an application user account and password prior to being placed in an application role and having one and only one user session at one time. The application shall log all successful and failed authentication attempts to access the application.

The steps developed within the application test case would then include the following:

1. The application shall display a use logon screen.

2. The user shall enter a user ID and password.

3. The application shall validate the entered user ID and password.

4. If the user ID or password is invalid, the application shall display an invalid logon message.

5. If the user ID or password is invalid, the application shall log an invalid logon message.

6. If the user ID and password are valid, the application shall validate that this is the only signed-in location for the use account.

7. If the user ID and password are valid, the application shall log a valid logon message.

8. If the user ID and password are valid, the session shall be placed in an application role based on the use account membership.

From the above set of requirements, the application tester can now produce detailed steps to perform security testing of the authentication process. These security testing steps need to include testing as a good user, as an intentionally bad user, as an accidentally bad user, and as a user not authorized to access and use the application.

Other things that could be considered when testing authentication and authorization could include the following:

Setting up multiple sessions with the same and different information to overload the system

Valid/invalid/disabled accounts

Password changes/lockouts/resets

Elevating privileges (administrative versus nonadministrative)

Accessing screens/fields/tables/functions

Valid/invalid data in each field

Logging out versus aborting the application

Information disclosure on errors and aborting

Information and access within log files and alerts

Hidden fields—special areas to click to execute

Can you get to a command line (listing or seeing directory content)?

Can you put in extra characters in a field and get the application to accept them?

Use application security requirements to build security test cases.

Use existing testing cases and look at them from a security point of view to do additional testing.

Look at what can accidently or deliberately be done with the application.

Using the flaws listed above with many applications, the following table describes some of the tests that could be performed during the quality assurance testing to build security testing into the application life cycle.

Potential Software Flaw

Security Testing to be Included

Buffer overruns

Carefully check your buffer accesses by using safe string and buffer handling functions.

Use compiler-based defenses.

Use operating system–level buffer overrun defenses.

Understand what data the attacker controls, and manage that data safely in code.

Format string problems

Use fixed format strings, or format string from a trusted source.

Check and limit locale requests to valid values.

Integer overflows

Check all calculations used to determine memory allocations to check that arithmetic cannot overflow.

Check all calculations used to determine array indexes to check that the arithmetic cannot overflow.

Use unsigned integers for array offsets and memory allocation sizes.

SQL and command injection

Understand the database you use.

Check the input for validity and trustworthiness.

Use parameterized queries, prepared statements, placeholders, or parameter binding to build SQL statements.

Store the database connection information in a location outside of the application.

Perform input validate on all inputs before passing it to a command processor.

Handle the failure security if an input validation check failed.

Failing to handle errors

Check the return value of every function.

Attempt to gracefully recover from error conditions.

Cross-site scripting

Check all Web-based inputs for validity and trustworthiness.

HTML-encode all outputs originating from user input.

Failing to protect network traffic

Perform ongoing message authentication for all network traffic.

Use a strong initial authentication mechanism.

Encrypt all data for which privacy is a concern and err on the side of privacy.

Use SSL/TLS for all on-the-wire crypto needs.

Use of magic URLs and hidden form fields

Test all Web input, including forms, with malicious input.

Understand the strengths and weaknesses of the approach, if you are not using cryptographic primitives to solve some of these issues.

Improper user of SSL and TLS

Use the latest version of SSL/TLS available.

Use a certificate allow list, if applicable.

Ensure that, before you send data, the peer certificate is traced back to a trusted CA and within its validity period.

Check that the expected hostname appears in a proper field of the peer certificate.

Use of weak password-based systems

Ensure that passwords are not unnecessarily snoopable over the wire when authenticating.

Give one a single message for failed login attempts.

Log failed password attempts.

Use a strong, salted cryptographic one-way function based on a hash for password storage.

Provide a secure mechanism for people who know their passwords to change them.

Improper file access

Be strict and account what you will accept as a valid filename.

Race conditions

Write code that does not depend on side effects.

Be very careful when writing signal handlers.

Information leakage

Define who should have access to what error and status information data.

Use operating system defenses such as ACLs and permissions.

Use cryptographic means to protect sensitive data.

Failing to store and protect data securely

Think about the access controls the application explicitly places on objects, and the access controls objects inherit by default.

Realize that some data is so sensitive it should never be stored on a general purpose, production server.

Leverage the operating system capabilities to secure secret and sensitive data.

Use appropriate permissions.

Remove the secret from memory space once you have used it.

Scrub the memory before you free it.

Poor usability

Understand security needs and provide the appropriate information to help them get their jobs done.

Default to a secure configuration whenever possible.

Provide a simple and easy-to-understand message.

Make security prompts actionable.

Conclusion

If the application life cycle includes security from the beginning, then the security application testing will logically follow when performing the quality assurance and user testing. If security is not included throughout the application life cycle, it will be harder to accomplish good application security testing within the quality assurance and user test processes. Including application security testing within the application life cycle will reduce the risk to information assets within the enterprise.