Application Software Versus System Software

Business software is typically called applications. Software that supports the running of the applications is typically called system software, such as software that runs on the operating system of a server. The System/Application Domain refers to all the system and application software-related components.

It’s not uncommon to hear system and application terms used interchangeably. They are not the same. For the purposes of this chapter, we use the more precise definition given previously. Generally, any business software that an end user (including customers) uses to access data is considered an application. This includes email, word processing, and spreadsheet software. Conversely, the operating system, the software needed to run the applications, and software that allows computers to communicate over the network, or between devices, is considered system software.

A typical user often leverages both applications and system software seamlessly. Let’s consider a user pulling up the Microsoft Word application. The user types a memo then selects print. At an extremely high level, the Word application sends the memo to the operating system, which sends it to the print spooler software that temporarily stores print jobs. The system communicates with the printer that the job is ready to print, and the printer’s system prints the memo.

Application software is at the heart of all business applications. Application software can sit on the workstation, server, or be accessed through the cloud. For example, an application can display a screen by which customers and employees can select products and enter data. Once the information is collected, the application transmits the transaction to a server. The server can store the information in a database to be processed later or instantly processed the transaction, store the results, and display information back to the end user. Later an employee can extract data from this ordering application into a spreadsheet to track the total number of orders each month by product type. The application that took the order, the spreadsheet that tracked the orders, and the email that was sent to announce the company had record sales for the month are all examples of application software.

Protecting Data Privacy

Because the System/Application Domain centralizes much of your data and the processing of that data, you must protect it from disclosure or unauthorized alteration. Recall that ensuring data privacy essentially means allowing only authorized users to view or modify it. You can deploy layers of controls to restrict access to authorized users.

Although controlling access to data and resources can be challenging, in some ways it is a little easier than trying to protect data as you send it to remote locations. You can enforce strict rules that limit which users and programs can access your data. An unauthorized user must access your network, then access a server in the domain, and then run a program or access data in a database. There are several points along the way to place good security controls. You can implement several types of controls that make it difficult for unauthorized users to get to your private data. An important first step is to identify sensitive or private data and then design controls to protect that data.

Implementing Proper Security Controls for the System/Application Domain

The best security controls are simple layered controls. Try to avoid overly complex controls. Complex controls generally require more effort to configure and maintain and often provide more opportunities to fail. Your goal in designing security controls is to ensure they do their jobs and keep your data secure. Although deploying layered controls is generally considered to be sound security practice, be careful that you don’t create so many controls that authorized users have difficulty accessing the data they need. Try to search for controls that balance security and usability.

Security controls in the System/Application Domain generally fall into three categories. There are many potential controls, but the most important controls should isolate data, limit access to data, or protect data from loss through redundancy. Each type of control plays a part in keeping your data secure and your organization compliant:

• Isolate data—Because much of an organization’s sensitive data resides in one or more databases in the System/Application Domain, it is important to place barriers between sensitive data and other entities. You can use firewalls and your network design to isolate data. Your network addressing scheme can separate one or more nodes into their own subnets. A subnet is simply a part of a network. Other network devices, such as switches, can physically isolate subnets from other nodes.

• Limit access to data—Node and user access controls in the System/Application Domain are similar to access controls for other domains. Operating systems provide mechanisms to restrict object access by users or groups. You can also use network authentication to restrict which computers and devices can connect to servers that contain sensitive data.

• Protect data from loss through redundancy—Because the System/Application Domain exists to provide applications and data for your users, it has to be functional. You’ll need plans to ensure users can access your applications and data regardless of what happens. That means you’ll need to create redundant copies of data or employ other strategies to protect your organization from loss of data or functionality.

Several other domains support users and their ability to access applications and data. In one view, you can look at the System/Application Domain as the central repository of the data you are trying to protect. The System/Application Domain provides the security controls closest to your data. An attacker who has compromised enough controls to reach this domain doesn’t have much further to go. The controls you place in the System/Application Domain could be the controls that make the difference between secure data and data loss. Take the time to plan your security controls well.

Software Development Life Cycle (SDLC)

Software Development Life Cycle (SDLC) is a process to design and develop compliant software. The SDLC consists of phases that depict various stages of the software development process. There are various methodologies published on what is considered an SDLC approach. While many of these methodologies vary, they typically break down software development among the following phases:

• Business requirement analysis

• Software design such as architectural design

• Software development, i.e., coding

• Developer testing

• User acceptance testing (UAT)

• Deployment

• Maintenance

• Decommission

As illustrated by the listed phases, the SDLC process takes software from cradle to grave. An SDLC audit can maximize the success of a project by detecting its potential risks and weaknesses in the software before deployment. A software development process audit offers independent validation of the testing process and shows areas where it could be optimized. While not an exhaustive list, the following are several important SDLC components that should be audited:

• Business requirements are clear and comprehensive.

• Architectural design is consistent with the technology infrastructure and supportable.

• Testing criteria are well defined.

• UAT testing is representative of the real world and what would be found in production.

• Deployment contingency planning is in place in the event that the new software has to be backed out due to unforeseen problems.

• Maintenance requirements have been defined prior to deployment.

• Decommission plans have been considered when the software reaches end-of-life, such as how the data will be archived if needed for later recovery.

In the business requirement analysis phase, the systems analyst or IT professionals gather business objectives and define the information requirements needed to design the application. A requirements document is produced that summarizes the analysis of the IT project. This document should include success criteria established by the business such as speed of processing times and volume of data to be collected, processed, and stored.

In the software design phase, a technical design is created. The design will address every business requirement. Additionally, the design phase will validate the feasibility of the business requirements from cost to the organization’s ability to support the software. For example, a technical feasibility study examines whether the current information technology (IT) infrastructure makes it feasible to implement the software or if a new infrastructure is required. A legal feasibility study examines any legal ramifications of each business requirement and how the technical design must address these legal mandates such as the implementation of encryption. An operational feasibility study determines if the current business processes, procedures, and skills of employees are adequate to successfully maintain the software. A schedule feasibility study relates to the firm’s ability to meet the proposed deadline set by the business to build and deploy the new software.

In the software development phase, developers will start to build the entire system by writing software code. Additionally, the developer will work with other IT professionals to configure the supporting IT environment such as setting up the database or data feeds. The developer will obtain or create test data to understand how the code must collect, transmit, and store the information. While not technically in the testing phase, typically snippets or portions of code will be tested throughout the development progress.

In the developer testing phase, the developer’s goal is to ensure the functionality of the software is operating to the requirements and expectations of the business. Sound testing includes unit, integration, and functional testing, defined as follows:

• Unit testing means the testing of individual modules or functions within the application in isolation to confirm that the code each portion of the code is working.

• Integration testing means the testing of how the different modules are working together as a group.

• Functional testing means testing an end-to-end function or process to confirm that the code is working within the software and with external dependencies, such as external data sources.

The UAT phase is the final stage of any software development before deployment. Actual business users test the software to determine if it does what it was designed to do in the real world. This is where the business users determine if the software meets their expectations. The users should stress the software such as exceeding the number of the expected users to determine if the software can handle the unexpected volume.

In the deployment phase, there is typically a Go-Live or production sign-off. No system should be deployed without this user acceptance. Once deployed, the software will be closely monitored and, if needed, backed out if there are major problems caused by the software. Once successfully deployed, there should be a postimplementation review. This review should include how well the SDLC phases worked to this point, including whether all business requirements and any cost-saving anticipated were met.

The maintenance phase is the care and feeding of the software. This may include applying updates or patches to fix bugs or improve information security. Maintenance schedules are published, and maintenance windows are established so the users know when the application will be down. Good software design can reduce the amount of maintenance required. For example, creating automated feeds that adjust key functions, such as dynamically feeding product prices. Dynamically updating pricing tables could eliminate the need to bring down the software to load an internal pricing table within the software.

In the decommission phase, the application is at end of life and will be retired. Decommissioning process will notify the users that the application will no longer be available by a certain date. Leading up to the decommissioning date, the users are often moved to another application that provides the same or improved functionality. During the decommissioning process, data are moved and archived as required by the business and by law.