Employees represent the broadest category of users within an organization. Organizations are composed of departments and lines of business. An employee may be full-time or part-time. An employee may be in a customer-facing role or a corporate function. Regardless of their job in the organization, employees have unique information needs.

Successfully implementing security policies depends on knowing who has access to the organization’s information. Security policies require users to have unique identities to access systems, applications, and/or networks. This is typically accomplished by the employee entering a unique user ID and password.

Employees’ access must be managed through the life cycle of their career with the organization. There is always pressure to grant and extend user access to increase productivity. No one wants to wait weeks for a new hire to be granted access. Additionally, when a change to the business occurs, you might need to change employee access. Although there’s significant pressure to grant employees new access rights, the same pressure may not exist to remove access. Consider the following example:

Security policies require access to be removed when an individual changes roles. Without good security policies, you may find longtime employees with excessive access rights. They collect new access as they change roles and continue to retain access from their prior roles. Department leadership might not perceive this as a problem, especially when an employee uses this broad access to “save the day” during a crisis. Looking ahead, people may believe there’s no time to ask for additional access during an emergency. An individual who is able to execute transitions quickly might prevent the problem from escalating.

Excessive access rights represent a serious security risk. As individuals change roles, their access rights must be adjusted. Prior access rights that are no longer needed must be removed. New access rights must be properly approved and granted. This is for the employee’s protection as much as for the organizations. When a security incident occurs, one of the first steps is to identify who may have had access. This is accomplished by reviewing individual access rights. Employees can avoid suspicion if they have no access to the affected systems, applications, and information. Removing unneeded access also reduces overall security vulnerabilities. In the event an ID and password is compromised, a hacker’s access rights would be contained within the employee’s current role. Consider the following example:

Good security policies make clear that individuals have only the access needed for their jobs. Security policies outline how rights are assigned and approved. This includes the removal of prior access that is no longer needed. This accomplishes the following:

• Reduces the overall security risk to the organization
• Maintains separation of duties
• Simplifies investigation of incidents

Systems administrators may need unlimited rights to install, configure, and repair systems. With this elevated access comes enormous responsibility to protect credentials. A systems administrator’s credentials are a prime target for hackers. As a result, organizations should consider additional layers of authentication for administrators when feasible, such as certificates and two-factor authentication.

Security policies reduce risk by requiring monitoring of the systems administrator’s activity. The systems administrator should only use broad access to perform assigned duties. Let’s consider a database administrator. She needs access to apply patches, resolve issues, and configure applications. Yet she normally does not access customer personal information stored within the database. Logging administrator activity is one way to verify that access rights are not being abused. Logs record if administrators granted themselves access beyond the scope of their roles. Logs record the names of people who access customer personal information. Although you may not be able to prevent a systems administrator from accessing customer information, you can review the logs to detect the event.

With elevated access, systems administrators could just turn off the logs; however, the act of turning off or altering logs is also trackable. Many systems write an entry when the log service starts and stops. Additionally, logs can be sent to a log server. A log server is a separate platform used to collect logs from platforms throughout the network. Access to log servers is highly restricted. Analyzing logs can help you detect gaps in logs, which are an indication the log service was turned off. Analyzing logs can also help detect if they have been altered. Knowing that your activity is being monitored is a deterrent in itself. Security policies outline the requirements of what is logged and how often the logs are reviewed.

There’s a widely accepted approach that states systems administrators’ access rights should be limited to their daily routine tasks. Through a separate process, systems administrators’ rights can be elevated when they need to install, configure, or upgrade the system. The approach assumes that tasks associated with the elevated rights occur infrequently. Therefore, the additional process is not burdensome. Some systems administrators resist this approach. Having unfettered access makes their job easier in that they don’t have to request access before performing certain tasks. It can be hard to predict what their access needs are. As a result, they may feel asking for permission is cumbersome and creates unnecessary delays.

You can consider limiting administrator rights a leading practice in regulated industries. The approach is widely accepted in the financial services industry. Some of the advantages of granting elevated rights to administrators as needed include the following:

• It reduces the overall security risk to the organization. In the event the systems administrator’s credentials are compromised, access would be limited.
• It dramatically reduces the volume of logs to be reviewed to detect when an administrator abuses his or her access rights.
• It improves the alignment and understanding between technical tasks and business requirements.
• This approach records the business reason for the elevated rights being granted, which addresses why the security administrator accessed certain files.
  • This information can also be used to identify patterns of control weaknesses.

It’s not practical to log every access a busy systems administrator performs daily. The volume of logs would be excessive. Any review of these logs would lack context. It may be possible to see that an administrator accessed a file, but there’s no business context for the action. In other words, given the volume of log files, it would be difficult at best to determine which files the person should or should not have accessed that day. The approach described earlier in this section allows you to understand why the access rights were used. By the nature of the request, you know what files the administrator should access and the business reason why. For example, if you found that a security administrator had accessed a financial spreadsheet, was it to fix a corrupted file, or because he or she wanted to illegally access information used to buy or sell stock? When an administrator is fixing a problem, you have a record of the reason why he or she accessed the file. Knowing the business reason gives you the context.

The process for capturing business requirements and elevating privileges is well established. Security policies outline the process of temporarily granting elevated rights, which is often called a firecall-ID process. A firecall-ID process provides temporary elevated access to unprivileged users. The name implies the urgency behind granting the access to resolve a problem quickly. During a firecall-ID process, the issue or problem is defined in a trouble ticket. The trouble ticket is a complete record of what access was granted and the business reason. The ticket is then assigned to someone to fix the problem. When the problem is assigned, the individual is granted elevated privileges. The individual completes the work and then closes the ticket. When the ticket closes, the individual’s elevated rights are removed. FIGURE 9-2 depicts a basic firecall-ID process.

A firecall-ID process is an accepted way to grant temporary access for a number of activities, such as one-time events like special financial reporting. With this approach, you configure more detailed logging without generating excessive volume. This is because you will record more detail, but only when the elevated rights are turned on.

A number of variations to the firecall-ID process are illustrated in Figure 9-2. For example, requiring a help desk manager to approve a ticket may be an optional control that some organizations feel is unnecessary. Another common variation is to allow an administrator to open a trouble ticket, make a repair, and then close a trouble ticket.

This self-service capability may be important when an administrator wants to track unusual events. For example, suppose a database administrator (DBA) has a very stable environment with few outages and problems. To control the risk, the DBA’s normal access may not include unlimited access to the database. However, when the database system administrator (DBSA) identifies a problem, he or she may choose to use the firecall-ID process to gain the additional access quickly to repair the database and note the problem.

Security personnel are responsible for designing, implementing, and monitoring security programs. In larger organizations, the roles may be separated between those who define and those who implement the policies. Security personnel develop security awareness and training programs. They also align security policies with those of other parts of the organization, such as legal and HR.

Security staff must understand and implement different types of controls, such as management, operational, and technical. They have to wear many hats. On any given day, security staff may handle a variety of tasks. One day they may work with procurement to review a new software package for vulnerabilities. They may be woken up in the middle of the night to respond to a security breach. In many organizations, the security team is understaffed, so they must carefully prioritize the workload to focus on the greatest risks. The following are examples of the diversity of issues that security teams deal with:

• Audit coordination and response, and regulator liaison
• Physical security and building operations
• Disaster recovery and contingency planning
• Procurement of new technologies, vendor management, and outsourcing
• Security awareness training and security program maintenance
• Personnel issues, such as background checks for potential employees and disciplinary actions for current employees
• Risk management and planning
• Systems management and reporting
• Telecommunications
• Penetration testing
• Help desk incident response

Security staff roles and their associated access must be well defined. This includes limiting access to specific duties and, as appropriate, leveraging the firecall-ID process to gain elevated privileges. With this broad access come enormous responsibilities to protect credentials. The credentials of these individuals are also prime targets for hackers.

Contractors are temporary workers; however, they can be assigned roles like regular employees. The two major advantages of a contractor are cost and skills. These individuals comply with the same security policies as any other employee. There may be additional policy requirements on a contractor such as a special nondisclosure agreement and deeper background checks.

As short-term employees, contractors may not show the same loyalty to the organization as a long-term employee. Many security experts consider contractors a higher security risk than an employee. This is because the organization often hires these individuals from consulting firms, and the organization does not have full control over the consulting firms’ hiring practices or full access to their contractors’ job histories or performance reviews.

Contractors allow you to ramp up your workforce during peak periods. Contractors generally save organizations money over the long term. Although you pay contractors more than similar employees’ wages, you usually need contractors for shorter periods of time. In addition, contractors generally do not receive paid benefits, such as sick leave and vacation time.

Contractors can bring a variety of special skills to an organization. These skills can be valuable to a specific project or initiative. Maintaining these skills within your full-time staff may not be cost effective. For example, assume you are deploying a new technology to prevent data leakage. The project is to install a leading vendor package designed to prevent sensitive information from being emailed out of the organization. Your staff may be unfamiliar with the package and the technology. You can hire a contractor who has installed this product numerous times. The contractor has knowledge based on prior installations that cannot be achieved through training.

Contractors must be fast learners. Within a short time, they are expected to know your security policies. They also have to adapt to the organization culture. The firm placing the individual often completes background checks for contractors. If that is the case, it’s important to verify that the background checks are as thorough as those performed by the hiring organization. The other challenge relates to security awareness. Depending on the length of the engagement, there may be limited time to conduct the same caliber of awareness training as you do with existing employees.

Vendor employees need to be managed the same as salaried employees. Their access must be tied to their individual roles. Vendor employees must follow all the same rules and policies as an organization’s own employees. A vendor employee may be full-time or part-time. He or she may be in a customer-facing role or a corporate function. Regardless of their jobs in the organization, vendor employees have the same kinds of information needs as an organization’s employees.

However, vendor employees are managed directly by the vendor company. Consequently, that company will often manage their access. This adds both complexity and risk. Processes must be in place to ensure that the vendor company is managing its employees effectively. This includes notifying the organization when staffing changes require access changes. Here are some situations for which a vendor must provide notification:

• When individuals are hired or terminated
• When individuals change their roles
• When systems are added to or removed from the organization’s network
• When security configuration changes are made to the communications between the vendor and the organization, such as firewall rule changes

A vendor can significantly impact the security readiness of an organization. An organization is only as secure as the vendor systems connected to the organization’s own network.

Guests and the general public are a special class of users. Unlike other types of users who are assigned unique IDs and passwords, you might not know the identity of an individual accessing a public-facing webpage. This is common on the Internet. There are many applications on the Internet that are freely accessible to the public. When an individual wants access to one of these applications, an ID and password is not needed.

For example, let’s assume a website contains a Zip code lookup application in the demilitarized zone (DMZ). You enter a Zip code to find out which city is in the Zip code area. Assume the website is freely available. The cost of the site is supported by advertisers placing ads on the webpage. When someone keys in a Zip code, the corresponding city name appears. This is accomplished through a query to a back-end database that matches the entered Zip code with the appropriate city. Credentials are exchanged between the website server and back-end database server. Rather than seeing an individual accessing the database, the security controls may only see the credentials of the website server. This in itself does not create a security exposure if the application, network, and database are hardened.

The Zip code lookup application ensures that only a five-digit Zip code can be entered, which prevents a Structured Query Language (SQL) injection attack. SQL injection is a common form of hacker attack in which a SQL command is placed inside an input field. Hackers hope that when the input field is passed to the database query, they can execute their own commands on the database. Network controls ensure that only traffic from the DMZ application to the database server is permitted. These network controls (such as a firewall) would also ensure that the only traffic permitted is a SQL query from the DMZ application to the specific back-end database server. The back-end database server accepts a connection only from the DMZ application. The back-end database server also permits only one type of SQL query, which reads the Zip code entered and returns the associated city to be displayed. FIGURE 9-3 depicts these layers of controls at the DMZ application, network, and database layers.

In this specific website example, you can see that the application, network, and database would be well protected. It’s not so easy in the real world. In the real world, applications share website space and back-end database servers. A breach in one application can lead to a breach in another. Not all applications effectively test and limit what a user can enter. An application’s internal controls can be sound, but the application becomes compromised by a vulnerability in the operating system. Security policies outline the types of controls and hardening methods used to protect a server in the DMZ.

Public-facing Internet sites are prime targets for hackers. Hackers may sign up for a legitimate account on your website. Then, using that account, they may try to find ways to expand its authority or gain access to other customers’ information. To protect against this, keep the number of system accounts used in the application to a minimum. As much as possible, the DMZ should be used simply to capture and clean customer input and pass the user content to a back-end system. At a high level, think of the DMZ as having two main purposes: cleansing user input and manning secure communications. It’s the back-end system behind the firewall that performs additional content verification and the actual processing of the transaction.

When dealing with guests and the general public, you grant access rights to a class of users rather than to individuals. It’s important to remember that guests and the general public have different skill sets than your employees do. These individuals have not had the benefit of security awareness training, either. Assigning guest and public access can be accomplished in several ways. You can assign credentials to applications, servers, or types of database connections. You can also assign rights to a generic user ID or service account. Assigning credentials in the form of a hard-coded ID and password stored within an application is less secure. Security policies typically prohibit this approach to application credentialing. The problem is that if an application is compromised, the ID is also compromised. It also makes it very difficult to change the ID’s password without recoding or reconfiguring the application. As a result, a password used in this manner tends not to change very often. This creates a security vulnerability. A much better method of assigning credentials is using a method that does not rely on passwords, such as assigning a certificate. Assigning a certificate to an account, application, or server is fairly easy. The complexity and cost come in setting up the environment to maintain the certificates.

The following are some best practices when dealing with guest and general public access:

• From a policy standpoint, it is important to have a well-defined risk process that performs a detailed assessment of guest and general public access.
• Highly restrict access to specific functions.
• Penetration test all public-facing websites to detect control weaknesses.
• Don’t hard-code access credentials within applications.
• Limit network traffic to point-to-point communications.

There are many different types of control partners. The individuals can be auditors, operational risk or compliance processionals, or regulators. Even within these broad types of control partners, there can be subcategories. For example, financial auditors focus on financial operations. They look at the completeness, fairness, and representation in the organization’s financial statements. They look at the underlying processes and operations that produced the financial data. Financial auditors look at any potential control weaknesses that may call into question the accuracy of the financial statements.

Technology auditors are often referred to as IT auditors. They look at an organization’s technology controls and risks. They assess the controls for design and effectiveness. They ask questions such as “Do the controls address all the vulnerabilities, and are they working well?” They also look at how well an organization assesses technology risk in the context of the business processes.

Although financial and technology audit teams have distinct responsibilities, they often collaborate. This is referred to as an integrated audit. In an integrated audit, more than one audit discipline is combined for a single audit. For example, let’s assume a company purchases large amounts of equipment for its manufacturing process. The accuracy of the company’s financial statements depends in part on properly reporting these expenditures. Financial auditors look at the underlying financial data and accounting methods used to reflect these investments. Financial auditors may look at the depreciation method used. They might even challenge the completeness of the data. On the other hand, IT auditors focus on the underlying technology that captures, records, and calculates the financial results. IT auditors look at the security controls and the integrity of the data.

Operational risk and compliance teams often have the same need for access as do auditors. The operational risk team reviews the controls to ensure a business is operating within the acceptable risk appetite. This means that the business is not taking on too much risk. Compliance teams ensure that the business is following the law. Like auditors, these teams are specialized. They look at a variety of controls.

In a public company, an auditor reports findings to the business unit management and to the audit committee. Operational risk and compliance reports are often sent to the business and the company’s risk committee. This dual reporting serves several goals. It ensures that line management knows about control weaknesses so immediate action can be taken. It also ensures that risks get visibility at the highest level of the organization.

Security policies detail the controls in granting control partners access. For an IT audit this typically means access to security reports, logs, and configuration information. Auditors primarily need read access. Auditors have specialized tools that help analyze samples taken and record their findings. Within these specialized applications they are granted appropriate rights to capture the evidence and write audit reports.

Contingent accounts need unlimited rights to install, configure, repair, and recover networks and applications, and to restore data. With this elevated access comes enormous responsibility to protect credentials. These credentials are prime targets for hackers. These IDs are not assigned to individuals until a disaster recovery event is declared. As a result, they must be protected until they are needed.

One challenge is to know whether these IDs will work during a disaster. For example, assume a data center is hit by a hurricane and the systems must be restored across town. That’s not the time to find out you don’t have access to the backup data. It’s important that these contingent IDs be tested at least annually. It’s equally important that, during these recovery tests, IDs that are no longer needed be identified and deleted.

System accounts often need elevated privileges to start, stop, and manage system services. These accounts can be interactive or noninteractive. The word interactive typically refers here to the ability for a person to log on to the account. A system account that is noninteractive is one to which a person cannot log on. An interactive system account has a password that, if known, can be used by a person to log on to the account. System accounts are also referred to as service accounts.

Why this distinction between interactive and noninteractive service accounts? These accounts usually have elevated privileges. That makes them targets for hackers. Ideally, you wouldn’t want any system accounts to be interactive. That way there would be no passwords to steal, all accounts would be tied to specific applications, and hackers would have less opportunity to get in. But this is not an ideal world. Many system accounts have passwords that can be stolen. Strict controls must be in place to protect passwords for interactive system accounts. A firecall-ID process, as previously described, can provide such controls to restrict access to these sensitive accounts.