Generalized frameworks are useful for meetings where you've been put on the spot to come up with questions and possible risks associated with a new application. You might even find yourself walking into a meeting, taking out a blank sheet of paper, and writing "PPTM," "STRIDE," and "PDIO" at the top before the meeting ever starts.
People, processes, tools, and measures(PPTM) is a great brainstorming framework to examine an application from the macro level. Detailed specific technical review steps dominate this chapter. PPTM helps you to come up with your own steps quickly and efficiently as they apply to your unique situation.
People People in PPTM describes every aspect of the application that deals with a human. Ensure that the right people are involved in the planning, design, implementation, or operations for the project and that the right stakeholders are involved. If the application involves end users, then ensure that the application has controls around provisioning and deprovisioning access and that the end users have been involved in the components that they ultimately will interface with. There is little that's more embarrassing than to spend time and money rolling out an application just to find out that upper management doesn't approve or that the end users find that the interface is too complicated to use.
Process Process in PPTM describes every aspect of the application that is involved in a policy, procedure, method, or course of action. Review the interaction of the application with interfacing systems and verify compliance in security models or ensure firewalls are in place to protect the application from external applications, users, business partners, and the like. Procedures and policies should be written to support how the application is intended to be used. Adequate documentation also should exist to support technicians that need to maintain the application.
Tools Tools in PPTM describe every aspect of the application that deals with a concrete technology or product. Ensure the right hardware and environment exists to support the application and that the application interfaces with recommended technologies appropriate to your intended policies and procedures. Verify the application and infrastructure are tested and audited appropriately.
Measures Measures in PPTM describe every aspect of the application that is quantifiable conceptually, such as the business purpose or application performance. For example, verify the application meets well-documented and well-thought-out acceptance criteria. The application should solve the business problem it is intended to solve. Logs should be meaningful, and you should be able to measure the performance of the application and ensure you can support it.
STRIDE is a methodology for identifying known threats. The STRIDE acronym is formed from the first letter of each of the following categories and is an example of a simplified threat-risk model that is easy to remember and apply.
Spoofing Identity Identity spoofing is a key risk for applications that have many users but provide a single execution context at the application and database levels. In particular, users should not be able to become any other user or assume the attributes of another user.
Tampering with Data Users can potentially change data delivered to them, return it, and thereby potentially manipulate client-side validation, GET and POST results, cookies, HTTP headers, and so forth. The application should not send data to the user, such as interest rates or periods, that are obtainable only from within the application itself. The application also should carefully check data received from the user and validate that it is sane and applicable before storing or using it. For web and other applications with a client component, ensure you perform your validation checks on the server and not the client, where the validation checks might be tampered with.
Repudiation Users may dispute transactions if there is insufficient auditing or recordkeeping of their activity. For example, if a user says, "But I didn't transfer any money to this external account!" and you cannot track his or her activities through the application, then it is extremely likely that the transaction will have to be written off as a loss.
Therefore, consider if the application requires non-repudiation controls, such as web access logs, audit trails at each tier, or the same user context from top to bottom. Preferably, the application should run with the user's privileges, not more, but this may not be possible with many commercial off-the-shelf applications.
Information Disclosure Users are rightfully wary of submitting private details to a system. If it is possible for an attacker to publicly reveal user data at large, whether anonymously or as an authorized user, there will be an immediate loss of confidence and a substantial period of reputation loss. Therefore, applications must include strong controls to prevent user ID tampering and abuse, particularly if they use a single context to run the entire application.
Also consider if the user's web browser may leak information. Some web browsers may ignore the no-caching directives in HTTP headers or handle them incorrectly. In a corresponding fashion, every secure application has a responsibility to minimize the amount of information stored by the web browser just in case it leaks or leaves information behind which can be used by an attacker to learn details about the application or the user, possibly using that information to assume the role of an authorized privileged user.
Finally, in implementing persistent values, keep in mind that the use of hidden fields is insecure by nature. Such storage should never be relied on to secure especially sensitive information or to provide adequate personal privacy safeguards.
Denial of Service Application designers should be aware that their applications may be subject to a denial-of-service attack. Therefore, the use of expensive resources such as large files, complex calculations, heavy-duty searches, or long queries should be reserved for authenticated and authorized users and not be available to anonymous users.
For applications that don't have this luxury, every facet of the application should be engineered to perform as little work as possible, to use fast and few database queries, and to avoid exposing large files or unique links per user in order to prevent simple denial-of-service attacks.
Elevation of Privilege If an application provides distinct user and administrative roles, then it is vital to ensure that the user cannot elevate his or her role to a higher privileged one. In particular, simply not displaying privileged-role links is insufficient. Instead, all actions should be gated through an authorization matrix to ensure that only the permitted roles can access privileged functionality.
PDIO comes from Cisco Systems and stands for planning, design, implementation, and operations. Sometimes it's important to consider the potential challenges at each stage of a project. You might find this framework useful as you look at a new application and think ahead to the upcoming challenges. There might be a problem, for example, if system administrators are tossing around ideas in a planning or design session for a network solution and the senior networking engineer isn't in the room. If you as an auditor are asked to look at the implementation of a new solution, you should immediately ask questions about the ongoing operations of the solution.