HIGH-QUALITY, SECURE, AND FUNCTIONAL applications and Web sites do not happen by accident. Rather, they are the result of many tests and retests. The end products are the applications and Web sites we use every day. To help ensure a successful deployment, an application must follow the software development life cycle, a framework that identifies stages from concept to deployment.
This chapter explores how applications are developed and thoroughly tested for vulnerabilities. The chapter also explores applications in production environments and they how are monitored and improved throughout their life cycle.
In the programming world, there are development and production environments. Both are important and both are part of the software development cycle. The purpose of the development environment is to develop, write, and upgrade software systems' applications. It is an area for programmers, coding, ideas, and application testing. It is where applications are conceived and created, separate from the real business environment.
A production environment refers to a real-world environment in which software runs the business. When an application reaches a production environment, it should be ready for public release. The application must be thoroughly tested and retested before it reaches the production environment. Bugs, however, are found in released applications, so support should be in place to resolve bugs. To address bugs and security holes found in applications within the production environment, patches and service packs are created and distributed.
Software development is comprised of several phases, or a life cycle. This cycle represents the stages software applications pass through from concept to development to a production environment.
As described in Chapter 8, every application must pass through several phases on its way to release. This is to ensure quality in performance and security. Before any application is tested in a production environment, it progresses through the software development life cycle (SDLC). The SDLC uses different stages that describe the stability of a piece of software and the amount of development it requires before final release.
A life cycle provides the framework that guides a software development project in terms of prototypes, designs, implementations, tests, and release dates. The exact steps for the SDLC vary by development environment, but the following list provides the types of steps used in the SDLC:
Pre-alpha—In the pre-alpha phase, the application is in its introductory state. Developers are unsure about which features to include in the application, and developers' roles may not be firmly established. The pre-alpha phase is the concept phase in which software functions and features are conceived, added, and rejected.
Alpha—In the alpha stage of the SDLC, an application is coded and various features are added. The software is tested and initial bugs are found and repaired. Software testing occurs in the alpha stage to help isolate bugs. The alpha stage may also see a feature freeze, which means development continues but no additional features are added to the product.
Beta—In the beta phase, the software is ready for limited release to conduct usability testing and test the application in a production environment. This is known as a beta release. Users are known as beta testers. Beta testing may reveal additional programming bugs, and developers fix them as needed.
Release candidate (RC)—A successful beta release leads to an RC, which is a potential final version. The RC version of software has gone through several stages, and most of the bugs and usability shortcomings have been resolved. Often, an application goes through more than one RC version, such as RC1, RC2, and so on. If no major flaws or bugs are found, the last RC version is upgraded to the final release version, and the software can be deployed.
There are many elements to application development and network management. One of the more important tasks for administrators is documentation. Well-functioning and secure networks and well-developed applications have many policies, procedures, and documented configurations. Policies, procedures, and configurations are unique to every network and application environment, so every organization should have clear documentation for its network and security infrastructure. Similarly, applications need useful and thorough documentation for administrators and users. Creating the manuals is an unpleasant but necessary task for developers.
Change management refers to a standardized approach to handling changes to the IT infrastructure and programming environment. Application development is a dynamic process, with changes occurring frequently to add new features and fix bugs. Key to change management is the documentation involved to ensure that standardized methods, processes, and procedures are used for all changes. Proper documentation facilitates efficient and prompt handling of changes, and maintains the proper balance between the need for change and the potential detrimental impact of changes. This is equally true for managing networks and for developing applications.
Network documentation comes in various forms, including policies, standards, procedures, and guidelines. Each of those documentation forms is discussed in detail below.
By definition, policies are an organization's documented rules about what is to be done or not done, and why. Policies set requirements at the highest level in an organization and are enforceable. Lower-level documentation may detail who can and cannot access particular coding systems, create consistent application outcomes, access network resources, respond to security vulnerabilities and how to respond to them.
Although networks have different policies depending on their needs, some common policies include the following:
Application development policy—Used to regulate software development and code management.
Network usage policy—This policy sets acceptable usage for network resources, such as PCs, printers, scanners, and remote connections. It outlines what can be done with network resources and consequences for rule violations.
Internet usage policy—This policy specifies how the Internet can be used on the job. Typically, usage should primarily focus on business-related tasks. The policy might state that incidental personal use is allowed during specified times.
E-mail usage policy—This policy emphasizes that e-mail must follow the same code of conduct as expected in other forms of written or face-to-face communication. All e-mails are property of the company and the company can access them.
User account policy—This policy typically states that each user is responsible for keeping password and account information secret. All staffers are required to log off their systems when they are finished using them. The policy may include violations, such as attempting to log on to the network with another user's account information.
Wireless security policy—This policy dictates what can be done with a wireless connection and the protocols that will be used to secure both the access point and the wireless communication.
Standards security policy—This policy identifies configuration and maintenance requirements of systems on the network, such as using strong passwords and applying patches in a timely manner.
Table 11-1. An example of a network risk assessment.
NETWORK DEVICE | DESCRIPTION | POTENTIAL RISK | USER ACCESS |
|---|---|---|---|
Network switches | Centralized network devices can disrupt network functions if successfully attacked. | Medium | Physical access to switches is restricted to administrators. Administration control to switches is guarded using role-based access control. |
Network routers and wireless access points | Routers are used to route network traffic. By using a compromised router, an attacker may be able to route network traffi c to perform a man-in-the-middle attack. | High | Access is controlled and restricted to administrators and is guarded using role- based access controls. |
Firewall | A firewall protects one network from another, typically a private network from a public network. | High | Access to firewall servers and configurations is tightly controlled limited to a few. |
E-mail servers | E-mail servers maintain corporate e-mail. A compromised e-mail server may reveal internal company information. | High | Administration of company servers is tightly controlled and restricted to qualified and trusted e-mail administrators. |
SQL database | The SQL database holds sensitive information. A compromised database can result in intellectual property and/or revenue loss. | Extreme | Database access is tightly controlled using physical and logical access controls. |
In addition to application policies, a network may have security policies covering everything from e-mail to logical and physical measures. These policies help ensure the security of the application development network. Often, security policies are developed by first creating a risk analysis. A risk analysis should identify the risks to your network, network resources, and data. The foundation of a successful security policy rests upon a risk analysis. Table 11-1 shows an example of a network risk assessment.
Note
The terms "regulation" and "policy" are often used interchangeably; however, there is a difference. Policies are written by an organization for its employees. Regulations are actual legal restrictions with legal consequences. These regulations are not set by organizations but by applicable laws.
Table 11-1 shows how a risk assessment is created and the risks incorporated into a security policy. The risk assessment is a key component of the security policy and identifies who is responsible for what, and which security controls are applied to protect the network.
Similarly, the policy governing application development should require consideration of security. Securing code begins with involving security subject matter experts in the earliest discussions.
In general, standards provide a means of ensuring quality. Standards in computer programming ensure a level of quality and a level of performance. Standards are often implied but many standards are also well documented and reviewed by all. Programming standards provide a foundation and a common ground when writing code and developing applications.
Developers learn how they must write their code from programming coding standards and related documents. Standards prevent programmers from writing code to their own preferences, styles, and substance. Standards ensure that applications are developed in a consistent style and allow programmers to flow between projects with relative ease.
Programming standards are applied within an organization and follow industry programming standards. Important characteristics of programming standards include the following:
Improve the compatibility of the code.
Create easier collaboration of projects.
Provide more manageable troubleshooting practices.
Provide a uniform approach to solving problems.
Are easier to maintain source code.
Help to maintain secure coding.
Procedures differ from policies in that they identify the way in which tasks are performed. For example, ensuring that programming is backed up is a primary concern. Therefore, each administrator has backup procedures identifying the time of day backups are done, how often they are done, and where they are stored. The policy will dictate who performs the backup, where they are stored and who can access them. The procedure tells how the policy will be followed. For an organization's internal application developers, connecting a new application to a sensitive database must follow a procedure. Procedures apply to networks and application development both for practical reasons and for security reasons. Perhaps the most important benefit of having documented procedures is consistency and standardization. You want little or no difference between how people accomplish tasks. Procedures build confidence that systems will operate as planned and expected.
The number and type of procedures that administrators and developers must be aware of depend on the organization. The overall goal is to ensure uniformity and that tasks follow a framework. The overall goal of application development also is to ensure uniformity and that security is consistently considered. Without a procedural framework, different administrators and developers may approach tasks differently; this leads to confusion.
Some documented network procedures include:
Programming procedures—These may set the programming languages used, type of code used, testing procedures, and more.
Security procedures—Some of the most critical procedures involve security. These identify what the administrator must do in the event of a security breach; security monitoring and researching, and applying security updates.
Network monitoring procedures—A network needs to be constantly monitored. Network monitoring procedures include reviewing bandwidth, applications errors, network operating system updates, and more.
Software updating procedures—All software must be monitored and updated periodically. Documented procedures dictate when, how often, who, and why these updates are done.
Procedures for reporting violations—Every network likely will have procedures for reporting violations. These may include physical theft, social engineering, authentication violations, and more.
Policies and standards are enforceable documents. Employees found in violation of policies and standards may face disciplinary action. Guidelines, however, are different; they typically are suggestions or tips that are usually not enforced. Guidelines provide suggestions for better systems and methods to complete tasks. In this respect, issuing guidelines is similar to offering best practices. Although guidelines do not require mandatory compliance, they form an important part of network security documentation and management. For application development, numerous guidelines or best practices are available to emphasize the importance of secure coding practices.
Before any Web site goes live and is deployed in a production environment, it is essential to test its functionality and usability. Various guidelines and procedures provide a framework to ensure that when a Web site is released, it has been tested and is ready for full-scale operation. Web sites have to be tested in both the development stage and limited production environment to ensure operability and prevent end-user frustration.
Among the many elements to consider when deploying a Web site are those pertaining to overall functionality, usability, and security. Each of these areas must be verified before a Web site can be successfully deployed and launched for widespread distribution. To help ensure Web sites meet a standard of functionality, many organizations develop checklists that are reviewed and followed before Web sites are released. Web site deployment checklists vary, there are considerations common to most deployment plans:
Verify links—Take the time to ensure that all links work and connect to the correct locations. Look for broken and failed links. Many link-check utilities are available online to automate the process, including the link-check utility located at
http://validator.w3.org/checklink. However, for internal or intranet pages, you may require separate software. Checking links is not a one-time endeavor; rather, it must be done periodically to verify that all links are still current.Test browser compatibility—Web sites may display differently depending on which browser is used. For example, browsers used with mobile devices display differently than a browser on a desktop system. The bottom line is: Just because a Web site looks great in one browser doesn't mean it will in another. Some scripts and functions work fine in one browser and might not work at all in other browsers or devices. Minor tweaking can resolve many cross-browser, cross-platform functionality issues. Part of the deployment checklist should involve verifying the Web site in all commonly used browsers.
Test all downloads—If your site offers downloadable files such as courses, event calendars and so on, verify that the download feature works and users are able to access the downloads.
Verify digital certificates and Secure Sockets Layer (SSL) URLs work correctly— If the Web site has secure communication requirements, ensure that SSL uniform resource locators (URLs) and Hypertext Transfer Protocol Secure (HTTPS) are configured and working correctly.
Test forms and form controls—Are the forms of the Web site secure? Verify that forms use input validation strategies to prevent injection attacks.
Verify path traversal—Is the directory structure secure? Verify that path traversal is not possible; attackers should not get outside intended directories.
Review navigational structure—The navigational structure should be tested both for active links and for usability. Navigational usability is often tested using beta testers to ensure navigation flows logically.
Verify shopping features—If your Web site includes a shopping cart or similar functionality, thoroughly test back-end operations to ensure that all transactions are secure, and everything runs smoothly.
Web page load times—Web sites that are slow to load due to heavy graphics or other features frustrate visitors. Web site checks should test and improve Web page load times.
The previous examples highlight security, usability, and overall function of Web site features that may be included in a test plan and functionality checklist. In addition to these criteria, functionality testing can verify that information is organized, available, and relevant to the visitor. This is particularly important on the first page of the Web site to catch the reader's attention. This information may include:
The headline—The headline is the sentence at the top of your page that your visitor often sees first. Scanners have no choice but to see the headline, and it might be all they see. The purpose of the headline is to attract visitors' attention and entice them to keep reading. This is an integral element because almost everyone will read your headline.
A value or proposition statement—The value or proposition statement is a concise, clear sentence stating what the visitor can expect from your site. It lets visitors know they are on the right site.
Benefit statements—Benefit statements are not to be confused with your value statement or features of your product. Benefit statements show how your product or service solves an immediate problem. These statements go right to core of the matter by answering "What's in it for me?" Benefit statements often address base motivators like saving time, making money, increasing business, improving looks, and so on.
A call to action—Just as it sounds, the call to action is a command that tells your visitors what to do. Be clear. Tell your visitors exactly what you want them to do.
Images—People are attracted to images. When buying a product they cannot touch, they want to know what it will look like. Images can be very effective in demonstrating a product and helping visitors become more connected to it, such as when they see people in a picture using it.
Navigation—Navigation is considered part of the information you offer because it provides links to important pages such as contacts, privacy statements, and guarantees. All play an important part in the decision to buy from your site. Landing pages typically have a different menu and header navigation format than the rest of a site; this keeps visitors on the page, reading, rather than enabling them to click away to another part of the Web site.
When developing a pre-deployment test plan and functionality checklist for a Web site, it is important to cover all key areas of the Web site, including security, functionality, usability and readability. When all of these areas are tested in a production environment, the Web site is ready for widespread deployment.
As mentioned previously, all software passes through the software development life cycle on its way to being deployed in a production environment. In each of these phases, testing plays an important role. Testing and authenticating software applications to ensure conformity to approved standards is a key component of the success of an application.
Different methods and testing strategies are used to achieve common goals—removing all the bugs and errors from the code and making the software error-free and capable of providing a reliable application. The different types of software testing techniques and methodologies include:
Black box testing—A black box testing methodology looks at the available inputs for an application and what the expected outputs are from each input. Black box testing assumes no knowledge of the inner code or application processing.
White box testing—A white box test examines the code of an application. White box testing is the most intensive, costly, and detailed of testing methods.
Gray box testing—A gray box testing methodology is the middle ground between black box and white box testing. It looks at the input and output of applications and requires a knowledge of the inner workings of the application.
Unit testing—With unit testing, a programmer verifies that individual units of source code are fit for use. A unit is the smallest testable part of an application.
Integration testing—With integration testing, individual software modules are combined and tested as a group. Integration testing typically occurs after unit testing.
System testing—System testing typically combines all the components that have successfully passed integration testing and assesses the system as a whole. It tests combined components to test their interoperability.
Regression testing—Regression testing checks for additional errors that may have been introduced in the process of upgrading or patching to fix other problems.
Usability testing—Usability testing is designed to check the actual usability of the application. This may be done in a limited production environment to get a sampling of potential application users. The usability test helps ensure that the application is user friendly and provides an intuitive interface.
Performance testing—Performance testing provides an accurate view of how applications perform in a large-scale deployment in a variety of production environments. It tests responsiveness under various workloads to ensure that the application works well under normal operational circumstances.
Software stress testing—In software stress testing, an application is pushed to its limits to see where the breaking points are. Stress tests go well beyond normal, real-world scenarios to find the limits of the application.
Recovery testing—Recovery testing gauges the recovery capabilities of an application in the event of failure. It tests whether the application can recover from a crash or hardware failure.
Security testing—Security testing checks the security of an application. This includes testing for injection attacks, path traversal attacks, and whether the software is vulnerable in other ways. These vulnerabilities need to be addressed before the software is released.
Compatibility testing—Interoperability is a significant concern, and application testing must ensure compatibility with other popular software. Compatibility testing is designed to verify how well an application functions with other software, such as the operating system or other Web applications.
Regulatory compliance testing—Coding must follow regulatory standards, and regulatory compliance testing ensures that the application meets and adheres to appropriate standards.
As shown in the preceding list, application testing is an involved process requiring a multi-layered approach to testing and problem discovery. It is all of these tests and procedures that help ensure quality, functionality, usability, and security of modern applications.
A key component of the software development life cycle is verifying that the application is secure. Tests of an application's security can happen in any phase of the SDLC; however, in the alpha and beta phases, there should be constant security testing. It is hoped that security holes will be caught when the application is released in limited form as an RC, and certainly before it is deployed in final form. As we know, however, many applications are released with significant security flaws that are not discovered until the product is in use and a vulnerability has been exploited. This represents a failure in keeping security in mind throughout the SDLC.
Key areas that must be considered as part of overall security vulnerability testing include the application's design, default security measures, mass deployment security, and information and response abilities.
Design security—Many security flaws can be traced directly back to the basic architectural design of the application. If detected early, these design flaws can be addressed in an early stage of development. Alpha testing is often critical in detecting design security holes. Ideally, security vulnerabilities would be eliminated in the code with a stringent review.
Default security—Out-of-the-box secure applications are important. Default application security measures should include applying the principle of least privilege. Features should be off by default. In other words, restrict features using an "enable feature" option rather than a "disable feature" approach. This helps ensure that users will enable only the parts of the application they actually care to use while minimizing vulnerabilities from features users do not need.
In an ideal world, an application would be secure when deployed in its default configuration. This is rare. Rather, security holes continue to be found and demand mitigation and retesting. Once a complete security assessment has been performed and security holes found, developers must correct all problems that have been found. These problems range from usability issues to security holes.
Managing security holes and bugs found in applications is not an ad hoc process; rather, it follows a framework designed to address each issue by priority. To mitigate security holes, the following steps can be taken:
Outline vulnerabilities—The first step is to identify all known vulnerabilities. This information can come from error logs, auditing, or from end users.
Classify vulnerabilities and establish a priority—Security holes range from mild to extreme. Each security hole must be evaluated to determine its threat potential. All vulnerabilities must be mitigated, but a best practice approach is to manage those with the greatest threat potential first. Often, the highest risks are threats that may lead to compromised data.
Develop a mitigation plan—Once you know the vulnerabilities and have prioritized them, it's time to determine how long it will take to fix the problems and develop a mitigation plan. The plan includes timelines, establishing who is responsible for what, and documentation procedures. You'll need to document details of what was done to address a vulnerability, who did it, and why. This helps as a reference should the information be needed again.
Retest—It is hoped that the mitigation plan worked and that the security vulnerabilities have been adequately addressed. To confirm, it is necessary once again to put the application through a series of security-related tests. Known as regression testing, these checks look for additional errors that may have been introduced in the process of upgrading or patching to fix other problems.
Once all the tests have been completed, the next step is to deploy the application to a production environment. The deployment can be limited to a small group or can be a wide-scale, unrestricted deployment. In either case, the application development process is still not complete. Once an application has been deployed, continued monitoring is required to verify how well it operates and what areas, if any, need to be improved upon. Some of the tasks that are performed while an application is in a production environment include:
Error messages—Error messages sent from the application to the developer help isolate what problem has occurred and why. If an application crashes, the error code can be sent to the developer for study. The developer may find the error stems from resource limitations, compatibility issues, security holes, and more. Once an error message reveals a problem, the developer can fix it with a patch or other means. However, as discussed in prior chapters, error messages should not reveal to an attacker any internal working knowledge of the coding.
Response time—If problems are found in an application, it will not take long for developers to hear about them. Many organizations employ mechanisms to track feedback about a product, looking for both the good and the bad. Once a problem has been flagged in the production environment, response time is critical. If it is a major security breach, a press release may warn of the danger, to be followed as soon as possible by a patch. Response time to incidents is critical when an application is deployed to a production environment.
Continued development—By the time an application has been released, it is likely that changes in the IT landscape have occurred. While an application is in the production environment, developers once again may return to the drawing board to discuss new features and enhancements. Part of this process may include having development teams use feedback from users who may have concerns about security vulnerabilities, features, usability suggestions, general product issues, or praise.
Tracking and monitoring Web site traffic are critical for identifying trends and key visitor demographic statistics. There are many ways to track visitor behavior on a Web site including directly from the source, such as surveys, forums, usability studies, and focus groups. All provide methods to identify areas on the site that need to be tuned, updated, or secured. In addition to these methods, another great strategy for gathering information is tracking or analytic software.
Analytic software reveals statistics that are invaluable for identifying Web page trouble spots. Among the statistics on your Web page that can be identified using software such as Google Analytics are:
Browser statistics—Analytic software can identify the browsers visitors use, such as Firefox, Chrome, Internet Explorer, Safari, and so on. In addition, you can see if visitors are coming to your site directly by typing in URLs, perhaps due to offline marketing efforts.
Bounce rate—The percentage of single-page visits to a Web site, or those visitors that "bounce away" to another site. The bounce rate is a standard measure of quality and relevance to the visitor. The lower the bounce rate, the better the site.
Network performance—Use these statistics to understand Internet connection issues including load times. It is possible to track how fast your page is loading on various Internet connections. If your page is loading too slowly, visitors will bounce almost immediately.
Visitor paths—The tracking software tells you where people visit on your page. This can help you identify navigation issues and where people go before they bounce off the site. If visitors are commonly bouncing from the same page, that page may need tuning.
Shopping cart abandonment—Tracking software enables administrators to see if visitors are abandoning the site at the shopping cart. This often indicates a confusing checkout procedure.
Visitor location—Your tracking efforts can also determine where the bulk of your visitors come from. You can track by broad area, such as country—Canada, United States, the United Kingdom, and so on—or by state or city. This helps you tune your page for location.
Analytic software can be configured to explore other statistics than those mentioned above. Which statistics used will depend upon the Web administrator's needs.
Web sites and Web applications are complex and require constant monitoring to discover and manage vulnerabilities. Assuring quality of production Web sites is an ongoing process encompassing many facets. Listed below are several best practices to consider when assuring the quality of a Web site.
Protect data—Data is the most critical element of a Web site and must be secured. Strong Web sites incorporate standards, policies, and protocols designed to protect data. All data should be handled securely, using strong encryption protocols while data is in transit and while stored.
Minimize data collection—Securing sensitive data is one thing but not having it in the first place is even better. Whenever possible, restrict the amount of personal data collected. This reduces the security risk.
Use tracking software—Tracking and analytic software allow developers to have a good idea of the demographic coming to the site and the technologies they use. Analytic software allows developers to customize the site for the demographic and to have a better idea of who is coming to a site and what they are doing there.
Conduct usability tests—Use online surveys, polls, questionnaires and other measures to obtain feedback from your demographic on Web site usability. Find out what they like and don't like; incorporate changes as needed.
Ongoing security testing—Use ongoing security tests to ensure that vulnerabilities are found and fixed.
Develop standards, policies, and procedures—Standards, policies, and procedures are designed to increase uniformity and in turn keep the quality of Web applications and Web sites high.
Use regression testing—After a security vulnerability or another issue or feature has been added, use regression testing to ensure the changes have not introduced new problems.
Use a testing cycle—Testing cycles ensure that the Web site or application is continually being monitored for vulnerabilities or other shortcomings.
This list represents a fraction of the guidelines for assuring a quality Web site. It is intended to show that many methods are available for securing production Web sites and ensuring that their quality remains high.
In today's computing world, security is taking an increasingly predominant role for Web sites and Web applications. Key to this security is testing and retesting applications, searching for vulnerabilities within the development of an application. Applications go through specific stages in development-pre-alpha, alpha, beta, and release candidates. Testing occurs at each of these levels and mitigation strategies are employed to reduce vulnerabilities.
Policies, standards, procedures, and guidelines are all forms of documentation designed to help ensure quality control over Web site and Web application development. Standards, procedures, and policies may be formal documents with consequences if not followed. Guidelines are more often suggestions, not mandatory to follow.
When testing applications, many methods are available, including black box testing, white box testing, gray box testing, regression testing, and compatibility testing. Each of these types of tests has a role within the testing cycle and each can be used to help ensure the usability and security of modern applications.
Black box testing
Change management
Compatibility testing
Development environment
Feature freeze
Gray box testing
Guideline
Integration testing
Performance testing
Policies
Procedure
Production environment
Recovery testing
Regression testing
Regulation
Regulatory compliance testing
Security testing
Software stress testing
Standard
System testing
Unit testing
Usability testing
White box testing
The bounce rate identifies the percentage of people who leave your site from the page they initially visited.
True
False
You recently developed an application. In which SDLC stages would the application likely be in just prior to being released to the production environment? (Select two.)
RC1
Alpha
Pre-alpha
Beta
Recovery testing analyzes how an application manages in the aftermath of failures and crashes.
True
False
As a software developer, you have recently coded a security patch to a Web application. Which of the following might you do after finishing the patch?
Perform a regression test
Perform a compatibility test
Perform a suitability test
Perform a gray box test
You have completed an application and now wonder if it will work with both the Microsoft Internet Explorer and Mozilla Firefox Web browsers. Which of the following tests might you perform?
Unit test
Universal acceptance test
Compatibility test
System test
_____ incorporates features of black and white box testing.
Regulations are not set by organizations but by applicable laws.
True
False
You are using a testing mechanism that looks at the input and output of an application to determine potential problems. Which mechanisms may be in use? (Select three.)
Black box testing
White box testing
Gray box testing
Brown box testing
Which of the following is often developed by first creating a risk analysis?
Web rules
Test software
Security policies
SDLCs
Standards are typically non-enforceable while suggestions are used to guarantee a level of quality and performance.
True
False