Application Security Controls

In the preceding sections in this chapter, our discussion centers on system architectures and development processes. You may wonder how you can make software secure in the first place. We discuss several techniques, characteristics, and mechanisms in the following sections.

Process isolation

With process isolation, running processes aren’t allowed to view or modify memory and cache that’s assigned to another process. For instance, if a user can see that a payroll program is running on the system, he (or any tool that he uses) won’t be able to read the memory space used by the payroll program.

Process isolation is a service that’s provided by the operating system. Mac OS X, Microsoft Windows, and Linux — and even much older OSs, such as RSTS/E, Kronos, and TOPS-10 — perform and provide this function. The system developer doesn’t have to build a wall around his or her application because built-in process isolation prevents others from snooping on it.

Hardware segmentation

Hardware segmentation refers to the practice of isolating functions to separate hardware platforms as required to ensure the integrity and security of system functions. This concept can also refer to keeping developers’ resource-intensive work off the production system. This is used to reinforce the concepts of segregation of duties and least privilege (these concepts are defined in Chapter 10) by preventing developers from accessing production systems.

Hardware segmentation is used to keep application developers off of production systems. It can also keep different applications or environments from interfering with each other.

Separation of privilege

Also known as least privilege, separation of privilege assures that no individuals or objects (such as programs that make requests of databases) have excessive functions on a system. For instance, in a finance application, you have at least three programs or functions involved in payments to others: those that request the payment, those that approve the payment, and those that perform the payment. Each of these individuals should have privileges that permit them to perform only their approved function, but no others.

Separation of privilege is quite similar to segregation of duties, which is the practice of dividing critical tasks among two or more persons, (discussed in more detail in Chapter 10).

Accountability

Accountability refers to an application’s ability to record every auditable event by describing the event: who made the change, what the change was, and when the change was made. This feature makes it impossible (you hope) for an individual to make any change to data without the application (or database) capturing details about the change.

Accountability is only as strong as the underlying authentication and access control mechanisms. If employees habitually share passwords or use each other’s accounts, then it’s very difficult to associate any inappropriate data tampering with a specific individual.

Defense in depth

Also known as layering, defense in depth is a security architecture concept wherein multiple separate mechanisms form protective layers around assets that require protection. For example, a company may have a firewall, but additionally implement host-based access control and other mechanisms. Then, if any one of these protections fails, the others still presumably run and prevent or detect security problems in the environment.

The effective and not-so-tired cliché of defense in depth is the metaphor of a castle protected by its moat, drawbridge, layers of walls, and other defenses. All work together to protect the treasure hidden deep within.

The practice of protecting a system or network with several concurrent mechanisms is defense in depth.

Abstraction

Abstraction is a process of viewing an application from its highest-level functions, which makes all lower-level functions into abstractions. Lower-level functions are treated as black boxes — known to work, even if we don’t know how.

Data hiding

Data hiding is an object-orientation term that refers to the practice of encapsulating an object within another in order to hide the first object’s functioning details.

System high mode

System high mode refers to a system that operates at the highest level of information classification. Any user who wants to access such a system must have clearance at or above the information classification level.

Security kernel

The security kernel is composed of hardware, software, and firmware components that mediate access and functions between subjects and objects. The security kernel is a part of the protection rings model in which the operating system kernel occupies the innermost ring, and rings farther away from the innermost ring represent fewer access rights. The security kernel is the innermost ring and has full access to all system hardware and data. User programs occupy outer rings and have fewer access privileges.

Chapter 9 discusses security models in depth.

Reference monitor

The reference monitor is a component implemented by the security kernel that enforces access controls on data and devices on a system. In other words, when a user tries to access a file, the reference monitor ultimately performs the Is This Person Allowed to Access This File? function.

The system’s reference monitor enforces access controls on a system.

Supervisor and User modes

Modern operating systems use the concept of privilege associated with user accounts. For instance, UNIX has the root account, and Windows Server has the Domain Administrator and Local Administrator roles. Only system or network administrators can use these accounts, with which they perform operating system and utility management functions.

Now and again, you may hear of administrators who grant root or administrator privileges to normal applications. Allowing a normal application these privileges is a serious mistake because applications that run in Supervisor mode bypass some or all security controls, which could lead to unexpected application behavior. For instance, any user of a payroll application could view or change anyone’s data because the application running in Supervisor mode was never told no by the operating system.

You use Supervisor mode for system administration purposes only. Business applications should always run in User mode.

Hackers specifically target Supervisor and other privileged modes, because those modes have a great deal of power over systems. The use of Supervisor mode should be limited wherever possible, especially on end-user workstations.

Service-Level Agreements (SLAs)

In the real world, users of any business application need to know whether their application is going to function when they need it. Users need to know more than “Is it up?” or “Is it down again?” Their customers and superiors hold the users of an application accountable for getting a certain amount of work performed in a given period of time, so consequently, those users need to know whether they can depend on their application to help them deliver as promised.

The Service-Level Agreement (SLA) is a quasi-legal document (it’s a real legal document when the application service provider is a different company than the organization that uses the application) that pledges the application performs to a set of minimum standards, such as

Hours of availability: The wall-clock hours that the application will be available for users. This could be 24 x 7 (24 hours per day, 7 days per week) or something more limited, such as daily from 4:00 a.m. to 12:00 p.m. Availability specifications may also cite maintenance windows (for instance, Sundays from 2:00 a.m. to 4:00 a.m.) when users can expect the application to be down for testing, upgrades, and service.

Average and peak number of concurrent users: The maximum number of users who can log on to the application at the same time.

Transaction throughput: The number of transactions that the application can perform in a given time period. Usually, throughput is expressed as transactions per second, per minute, or per hour.

Data storage capacity: The amount of data that the users can store in the application. Capacity may be expressed in raw terms (megabytes or gigabytes) or in numbers of transactions.

Application response times: The maximum periods of time (in seconds) that key transactions take. All response times for long processes (nightly runs, and so on) should be in an application’s SLA.

Service desk response times: The amount of time (usually in hours) that a service desk (or help desk) will take to respond to requests for support.

Security incident response times: The amount of time (usually in hours or days) between the realization of a security incident and any required notifications to data owners and other affected parties.

Escalation process during times of failure: When things go wrong, how quickly the service provider will contact the customer, as well as what steps the provider will take to restore service.

Because the SLA is a quantified statement, the service provider and the user alike can take measurements to see how well the service provider is meeting the SLA’s standards. This measurement, which is sometimes accompanied by analysis, is frequently called a scorecard.

Percentage	Number of Nines	Downtime per year
99%	Two	88 hours
99.9%	Three	9 hours
99.99%	Four	53 minutes
99.999%	Five	5 minutes