Principles

Network security administration is comprised of a base set of principles. Concepts such as accountability, least privilege, and authentication are all included in the SSCP examination because they are part of the SSCP CBK. These three areas work hand-in-hand to control the amount of damage a user could potentially inflict on organizational information resources, either intentionally or unintentionally.

System Accountability

Accountability within a system means that anyone using the system is tracked and held accountable for their actions. The organization must have methods in place to hold users accountable for their actions. Accountability applies to both intentional and unintentional actions. When a user knows they are accountable for their actions on the system, hopefully, they will tend to avoid activities that could damage that system. These actions could include something as simple as downloading an unauthorized piece of software from the Internet without running a virus scanner against the file before installing it. A mechanism is needed within the system that allows administrators to keep track of these actions and it must be transparent to each user.

At the core of accountability is system logging, also referred to as auditing. Accountability within the system requires the tracking of user actions on the system. In most cases, the operating system logging capabilities of the workstation can provide this function. All actions performed by the users are logged to a file that only the administrator can access. Actions of users can be verified by the administrator at the request of management, in the case of an incident, or even on random spot checks to verify the user's compliance with organizational security policies. The log files are accessible only to the administrator in an attempt at helping prevent the unauthorized manipulation of the log files. The types of actions typically logged include incoming and outgoing Internet traffic, access to internal servers and systems, and actions performed on each user's local workstation.

Although the logging of user actions provides a good method for tracking users on the system, it does not actually prove that the actions logged were performed by the user in question. Any normal user on the system could potentially be pretending to be another user, which could conceal harmful activity on the system. So how do you verify the identity of users while they are on the system? The ability of a system to provide verification of user's identification depends on the ability of the system to correctly authenticate the user.

Multifactor Authentication

Multifactor authentication is used to determine the right of an individual to access a physical facility or to access data within an information system. Information and data can be used interchangeably in this context. Authentication methods provide the basis for verifying the identity of users on the system. The users identify themselves by providing a user name or other identifier. But the identifier itself is not enough to say beyond a doubt exactly who entered that identifier and is using the system. The user must be authenticated in order to prove they really are who they claim to be.

Test Day Tip 

The authentication process is vitally important to nearly every aspect of security. Due to its importance, you can expect to see questions on the SSCP exam in relation to the authentication processes and mechanisms.

There are three types of authentication methods:

• Something you know

• Something you have

• Something you are

Multifactor authentication takes the traditional form of single factor authentication (a password for example) and expands on it by replacing or augmenting the single factor authentication. Multiple forms of authentication are utilized to better verify the identity of the user. Multifactor authentication adds steps to increase the security of the authentication process. Following are examples of some possible types of authentication factors used today.

• Something you know: passwords, personal ID numbers (PINs), pass-phrases.

• Something you have: smart cards, tokens, ID card, or physical keys.

• Something you are: Something physically attributable to you and only you. For example, fingerprints, palm scans, voice prints, iris scans, and retinal scans.

"Something you know" is by far the most used category of authentication methods. It is easy to implement and comes standard in most operating systems and applications. Passwords are the most recognizable form of this method of authentication. Another familiar form of authenticating a user using this method is the PIN. PINs are most commonly used in automatic teller machines (ATMs) because they are concise and provide relatively good security for limited use applications.

"Something you have" is a physical form of authentication. It consists of a physical object that can be carried with a person for use when the need arises. Car keys provide a form of authentication for getting into vehicles that have been locked for safety. Passports are another type of "something you have" authentication. Persons without a suitable passport find it difficult to be allowed entry into foreign countries or even back into their own. A more computer security-based authentication mechanism from this area would be the use of a smart card or Java-programmed "button," often used to access specific computer systems on a network.

"Something you are" is similar to the physical authentication methods used above, but users normally carry these things with them as part of the physical makeup of their own bodies. Retinal scans provide authentication by measuring the discrete differences in the blood veins in a person's retina. Palm scans depend on the lines on the underside of a persons hand to differentiate them from other users. Some facilities use voice scans to authenticate individuals. The usefulness of these types of authentication depends heavily on a person's physical attributes not changing. For instance, when an individual gets sick or pregnant it can change the blood flow in a person's body, thus affecting retinal scans.

Using each method on its own can provide a decent level of assurance that the user is who they say they are. But when more than one of these authentication methods are utilized at the same time, the security of the authentication session is increased and raises the level of assurance that the user is actually who they say they are. Multifactor authentication is more precise because the system expects the user to have more than one form of identification on their person at the time the authentication process takes place. The more forms of identification asked for, the less likely the authentication process can be spoofed or fooled by an intruder. The key to multifactor authentication is to balance the degree to which users are inconvenienced during the authentication process. The more inconvenience to the user, the more likely the system will end up misused.

For instance, to enter many network data centers, a person may be required to perform a palm scan (something you are) and then also enter a PIN on a number keypad (something you know). The chances of someone being able to get past the palm scanner and know someone else's secure PIN are less likely than either one of the two methods alone. Because the chances of someone having a palm print exactly like someone else's and that they also know their PIN is extremely low, it can be determined with a high level of confidence that they are who they say they are.

Exam Warning 

Pay close attention to the exam questions focused on these forms of authentication. It is easy to misread the questions or the provided possible answers when stressing about the exam. Just remember these keys to the authentication forms:

Something you know	=	Anything you keep in your memory.
Something you have	=	Anything physically carried on your person, but not part of your body.
Something you are	=	Anything physically part of a body, such as voice, eyes, hands, and so on.

Principle of Least Privilege

The principle of least privilege states that a user should only have enough access to the system to enable them to perform the duties required by their job. It is also a form of user management. Elevated levels of access should not be granted until they are required to perform job functions. Owners of the information in a system or the managers responsible for the information are the appropriate authority for authorizing access level upgrades for the system users under their control. Some common examples of least privilege are:

• Normal users do not need elevated access to the system to perform their job functions.

• Applications on a system should not run with more access than required to function correctly.

• Developers do not need administrator access to operational systems to develop new products.

• Least privilege limits access rights to only those required to perform job functions.

• The number of administrator or root level accounts on the system should be kept to a minimum required to keep the network operational and accomplish the mission.

• Administrator- and root-level accounts receive the most scrutiny when an attack occurs.

Normal users do not need access to administrator- or root-level accounts because that level of access is simply not necessary. A normal user is defined as an individual that utilizes applications or services running on a server without the intent of maintaining the application itself, or the server the application is running on. Least privilege also means that users do not have access to applications or services that are not required to perform their job, even if that access is not at the administrator level. For instance, users in the customer service department do not need access to the company accounting records.

This concept also relates to applications that run on an organization's servers. Applications running in the corporate environment should not be given access privilege to the system beyond those required to keep the application running correctly. Services that run with administrator access to the system will allow intruders to obtain that same level of access if the service is compromised. Restricting the access level of applications helps ensure that vulnerabilities exploited in the service will not result in a total compromise of the system.

Organizations that have a pool of developers sometimes find themselves faced with the quandary of whether or not the developers actually need root access to operational systems. The justification from the developers is that minor bug fixes can be implemented on the operational systems without slowing down the entire process with a configuration control and management process. The configuration control process is in place as a safeguard against changes in the system that could cause harm to the operational status of a system. Regardless of the good intentions of well meaning developers, access to these accounts should be restricted.

But why be so restrictive with system access? User and application accounts that have the greatest ability to manipulate the system are the most likely targets for intruders trying to compromise the system. Minimizing the number of root or administrator accounts lessens the likelihood of a successful intrusion attempt. Some applications, such as Web servers, receive the most attention from people on the Internet trying to break into systems.

Head of the Class…
Developers and Least Privilege

Security experts have often been asked questions concerning whether developers should have root or administrator access on operational systems. It is not usually a matter of trust, so much as it is a matter of requirement. Developers do not usually need root access to those systems because they are not the system administrators. There are always exceptions to the rule, but managers do not always know the best answer to these questions so they tend to bend in favor of simply getting the job done.

Through the course of a security assessment, experts often find developers with administrator or root access accounts to operational systems. Normally, this is where the applications running on those servers were written in-house by the developers. This is usually done with the approval of the managers because they honestly believe it makes sense for developers to have the ability to fix issues on the fly. The developers can be quite adamant that root access speeds up the process for making minor revisions or bug fixes to the software. Operational requirements often put pressure on managers and their developers to ensure that the applications continue to perform as efficiently as possible. Without a security process within the organization, operations will win out.

The truth be told, developers simply do not need root access to those systems because they are not system administrators. Developers create applications and software solutions within a controlled test environment so that it will not impact the operational systems. But if developers have the ability to make "on-the-fly" changes to the application while it is in an operational setting, the organization transforms the operational network into a test network.

There are times when developers make mistakes. Making those mistakes on operational systems could potentially bring the entire system down. If the system is down, many critical job functions within the organization cannot be accomplished, costing the company time and money. This is the reason we recommend both configuration management practices and least privilege.

A large number of organizations trust their developers because they are the ones creating the software that generates revenue for the organization. But once the possibility of bringing down an operational system because of a poor bug fix or the likelihood of a disgruntled developer creating back doors into those systems is pointed out to them, they start to look at things differently. It is important to bring the discussion to the forefront, but not to attribute blame. Developers should remember that if something does go wrong and they never had administrative access to the system, then it is less likely they were the cause of the problem.

As an example, look at a Web server that is accessible from the Internet but also resides within the company network architecture. Say the Web server is running with administrator privileges. The Web application in this scenario is found to have a buffer overflow within its code. An intruder finds the vulnerable Web server and attempts to exploit the problem, which allows them to execute arbitrary commands on the vulnerable system. If the Web application is running with administrator privileges, the commands executed by the intruder via the buffer overflow vulnerability will also run with administrator privileges. Using the principle of least privilege, the access level the Web server has to the system could be lower, thus lessening the impact of an intrusion to the system.

Least privilege also protects normal users who have no need for the administrator access levels. As said before, administrator and root accounts are the primary targets for intruders. When a serious security breach occurs, the individuals with privileged access receive the most scrutiny while investigating the attack. A normal user, while still important to the overall security scheme at the organization, will not normally be the first suspect.