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.
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.
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.
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.
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.
You use Supervisor mode for system administration purposes only. Business applications should always run in User mode.
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 |