Men and women range themselves into three classes or orders of intelligence; you can tell the lowest class by their habit of always talking about persons; the next by the fact that their habit is always to converse about things; the highest by their preference for the discussion of ideas.
—Henry Thomas Buckle
There’s a lot in this book so far about working with people. As the element with the greatest variability in your security program, people can make or break your efforts to manage risk. This chapter focuses on controls explicitly for dealing with people. In most sizable organizations, there is a human resources department (or person) dedicated to overseeing personnel operations. They have an instrumental role in building and managing the security program.
Policy for the People
Here is a sample security policy covering Human Resource security that outlines their responsibilities:
Sample Human Resource Security Policy
ORGANIZATION will ensure that all users including employees, contractors, and third parties understand their responsibilities, are qualified for their assigned roles, are aware of relevant security issues, and are held responsible for their actions. The Human Resources (HR) department will be responsible for the following security processes:
Employee on boarding and off boarding
The HR department will be responsible for overseeing the hiring and separation processes for contractors and employees initiating/terminating their work with ORGANIZATION. The HR department will track the processes for distribution/collection of company equipment and work with IT to ensure the prompt provision/removal of access rights. The ORGANIZATION assigns the primary responsibility for the provision/removal of access rights to the IT department. The IT and Security department will work together to ensure that only authorized personnel have privileges on the ORGANIZATION systems.
Background Screening
Because some ORGANIZATION employees and contractors will have direct access to sensitive information, prospective ORGANIZATION employees and contractors must be background screened before being they are granted access to sensitive systems or data. The HR department will own and maintain a documented process for performing background checks on potential employees and contractors. The Security department will work with the HR department to develop a standard describing the acceptable background check criteria that users must meet in order to be granted access to sensitive information. The Security department will work with HR to develop a standard and schedule for re-checking background checks on an ongoing basis.
Agreements
As ORGANIZATION has many terms and conditions of employment, HR, the Security department, and management will share the responsibility for ensuring ongoing training and compliance with the security policy, the code of ethics, non-disclosure agreement, acceptable usage policy, and the proprietaryinformationand inventions agreement.
Training
The HR and Security departments will be responsible for making sure all employees receive annual security awareness training as well as any needed security skills training. Some security-specific responsibilities may require additional skills and knowledge, HR and management will work to provide training resources as needed. The HR department will track and retain records of employee training, skills, experience, and qualifications as pertains to security matters.
Disciplinary Process
ORGANIZATION considers misuse of its IT systems or violation of security policy as grounds for disciplinary action up to and including immediate termination. The HR and the security departments will work together to ensure proper follow-up actions are taken in the event of a violation.
Employee Role Changes
An important part of user management is ensuring proper and authorized user account additions, closures, and changes. The HR department plays a pivotal role in keeping IT and security teams informed about employee changes, which can include on-boarding (hiring), off-boarding (termination), or role changes. It’s never fun to have a new employee start work and find that IT has no idea the person is starting that day. Then IT has to scramble to set up their account and get their equipment, which can lead to mistakes like giving the user too much access. IT needs to have adequate warning when new users are needed.
It is also helpful to have either a separate process or defined extra steps for account work involving system administrators and individuals with elevated access. You may want to include additional approvals, additional checks, and faster turn-around time on terminations for these types of accounts.
In the other direction, user account deactivations are even more important. Having an active user account open and available after an employee leaves the organization is big problem. First, it’s a security vulnerability to allow a former employee to have unauthorized access when you have no control over their actions. Second, it’s a threat to the employee, as they could be blamed for actions taken with their still active account. Third, it’s a glaring audit finding and in some regulatory regimes, a fine.
For security and sanity’s sake , all user accounts should be created and removed as part of a documented request and approval process. The goal is to be able to produce the entire chain of events when an auditor randomly picks out a user and says, “This guy here, it shows his account was created on August 15th, 2016. Show me HR paperwork authorizing his account creation and what level access he should have.” If you don’t have this, you will have a problem. Let’s hope that the problem is just an audit finding, and not a rogue user that someone created. The real question to fear from an auditor is this: “I see that Melinda quit on February 15th, yet she still has an active account on these systems. Can you explain that?” Usually the explanation is that someone flubbed up and you feel the need to crawl under a rock. To prevent these kinds of things from happening, it’s a good idea to have someone (like security) do periodic (at least quarterly) account reviews to ensure that every user can be tied back to an authorized person in the organization.
To unpack all of this, you should have procedures that include the following:
Standard user addition, termination, and modification
Administrative user addition, termination, and modification
Quarterly account reviews
In addition to these, you should consider attaching some service level agreements (SLA ) to ensure timely notifications and set expectations. Even if your organization doesn’t use internal SLAs, you can include time expectations as part of the procedure or standard in the preamble. Some things to define service level agreements on are:
IT needs notification at least X days for new accounts in order to set up a system and account
Termination notifications should be given at least X business days before the employee’s last day of service to ensure that the account is set to expire upon their leaving.
In the event of urgent terminations, IT and Security should be notified immediately so that appropriate measures can be taken.
That last item refers to a touchy but important area of user management: urgent terminations . This could be the unexpected firing of an employee or a round of layoffs. These are the painful separations where IT and Security need as much warning as possible. I realize that in the real world, this can mean a matter of hours or even minutes, and sometimes needs to be contained to only a few individuals. In any case, urgent terminations must be coordinated between HR and Security. These are the events where leaving an account open a few minutes after an angry person has left the building can lead to incidents with large impacts.
Background Screening
One of the most controversial security controls is background-check screening . Unfortunately, it’s also one of the more common controls in place. Some say pre-employment screening is necessary in order to properly investigate and weed out potential malefactors before being given access to sensitive information. This is why you see full complete checks of criminal and credit history required for all financial and medical organizations. Others say that overly broad background checks are invasive and discriminatory. Just in my own part of the world, two laws were been recently passed restricting pre-employment credit checks1 and criminal background checks2 in the Pacific Northwest. Both measures do have provisions for background checks where it is deemed “job related.” Considering the various compliance and security requirements of the sensitive systems, it looks like background checks are still going to be big part of security controls.
Since there is such a concern, there are many things that you can do to make sure that employee privacy is protected. First, make sure that you check extensively with the HR and legal when you embark on a background check program. The rules can vary quite a bit by venue.
Second, your checks should be proportionate and risk-based, not based on as how much information on a person you could vacuum up. Not every user may need the same depth of background check. Just remember if a user is moving from a lower level to a higher level of access, they should have additional background checks as needed.
Third, get the person’s consent. HR and legal will insist on this, but it still bears repeating. Usually background check requirements are noted in the job description and a consent form provided as part of the job offer process. In fact, some job offers should be worded so that they are contingent on the prospective employee agreeing to and passing the background check. You should also give the applicant a chance to disclose if they have any known violations or incidents that could come up in the background check. It says a lot about person’s character if they’re willing to reveal this about themselves instead of hoping that it won’t be uncovered in a records search.
Last, keep the background check private. At the very least, you need the person’s full name, home address, date of birth, and Social Security number. This data is by definition personally identifiable information, which should be protected. Only HR needs to see this and the details of the background report. Preferably, you can even limit this in HR to a specific individual or role performing the check. Even auditors and the security department should be barred from accessing the details of a person’s background check. In nearly every circumstance, security and auditors only need to verify that a check was performed, and the background-check cover page should be sufficient for that. If that’s not possible, an HR representative can simply black out the details on a photocopy to sanitize the audit record. You shouldn’t need to store background check details for more than two years, but you can hold onto the sanitized audit proof they were done.
When to Check
Nearly every security and compliance requirements list mandates a background check before a user is given access to confidential resources. The ideal time is upon hire before they are provisioned an account and office key. I have seen cases where employees were hired with pending background checks. In these cases, the security team blocked the issuance of login credentials until HR provided assurance that the check was done. It’s always awkward for a new employee to be on site but not have access to any computers, but it was the right thing to do. Organizations with more secure needs also repeat their background checks on all personnel every few years, just to make a new unknown criminal violation hasn’t occurred. Some organizations even have procedures in place to do covert background checks on users if someone reports them acting suspicious.
If a person has ended their relationship with the organization and then is returning (quit and then rehired), they should be considered starting from scratch as far as background checks have concerned. Some organizations give the candidate a few months of leeway, but the more prudent organizations re-do the check regardless of how much time has elapsed. This can also apply for contractors being transitioned to full time employee status. Background checks are relatively cheap to perform and another check can occasionally uncover interesting new facts. In other words, it’s a control that provides a meaningful risk reduction for its relative cost.
Who to Check
Everyone who has access to confidential information and systems (which are defined in your policy and scope) should be subject to background screening. This means physical and logical access to systems, so you would include janitorial staff and maintenance workers. Fortunately, most modern building management companies who cater to businesses can attest to doing this on all their staff. When I say anyone who has access, I mean anyone who can touch the systems without supervision or in the normal course of their work. Occasional vendor support personnel who need to work on your hardware can be escorted physically or electronically with screen-sharing software. If a vendor or contractor requires unmanaged access, they need to be checked or have their company formally attest to a background check. A note on these attestations: they should be in writing or in the contract and they should include information on what the individuals are background-screened against.
Any user given higher access should be checked as well. If you don’t do full background checks on normal users but then promote one to a database administrator of the payment card system, then you need to apply the full check at that point. This too is a common oversight, so be careful.
What to Check
Before we get into specifics of what should go into a background check, let’s revisit the purpose: to measure the risk of a user acting maliciously. The information you discover as part of a background screening provides information about a person’s past actions , which in turn inform you about their character and motivations. If any information is returned, it will likely point toward a person being untrustworthy. It’s mostly about disqualifying someone, not qualifying them. A completely clean background check is by no means a guarantee that someone will be honest and reliable.
One of the simplest and most useful indicators about a person’s character is to call and talk to their former employers and references. Make sure that you confirm the position title, the period of employment, and the job duties they performed. Establishing a good rapport with the reference can yield a lot of helpful information about the candidate. Since the majority of your candidates are unlikely to have criminal records, this technique will yield a lot of information you would not get otherwise. Remember to keep records of your conversation for both the auditors and in the event that there are any hiring-discrimination lawsuits.
Another easy verification is to check their educational and professional certification credentials. It’s surprising how often this isn’t checked; it’s also very revealing about the truth behind some inflated claims. These are both verifications that can be done without tripping over any privacy or legal restrictions.
When looking at background checking candidates from outside the United States, it is common to do a passport verification (which encapsulates some home country checks) as well as residential address verification for the past five to seven years. If the person has lived in several international locations over the past years (not uncommon for tech contractors), then each of the national jurisdictions should be checked.
The more serious background checks involve criminal, terrorist, and sex offender records. These are best done by a qualified agency that can run them and give you a report. Be sure to be thorough and include global, federal, and state criminal records. HR probably already wants to do a legal working status check, which includes citizenship or immigration status. Lastly, you can do a civil litigation records check to see if this individual is party has a history of being sued. Court records checks should go at least seven years back.
Background screening that includes credit checks are controversial to the point of being legally restricted in some states and countries. The good news is that a standard credit check does not affect the candidate’s credit score or ability to get credit. It isn’t the same type of credit check that is done during a loan application process. The goal here is to look for candidates who might be predisposed to theft because of large or serial debts. This could be indications of potential addictions or gambling problems that could put the person in a compromising position. Things like credit history, bankruptcies, tax problems, liens, and civil court judgements could end up these kinds of reports. These kinds of checks are usually asked for in any organization or position involving the direct access to financial data or transactions. The unfortunate problem is that many trustworthy individuals in modern America do have some blemishes on their financial record. It’s been my personal experience that these are usually because of previous large medical bills.
Where permitted by law, drug testing can be done as part of a pre-employment screen . Many organizations and jurisdictions do not condone drug testing, so be careful with this requirement. Some consulting companies often find themselves being pushed to have these done for staff doing work for military or financial organizations. This can become problematic given the privacy attitudes of some highly skilled IT engineers. Some may even reject the idea on principle. Lastly, in some state jurisdictions, adult use of some recreational drugs is perfectly legal, while remaining unacceptable at the federal level. This can create jurisdictional dilemmas.
What to Do When There’s a Problem
Most of the time, background-check screens come back clean. The only discrepancies you may encounter usually come up during the reference or previous employment checks (which is why I encourage doing them). However, if you have an issue, how do you proceed? The first question to consider is if they predisclosed the issue. If not, then there is a big question mark regarding the candidate’s honesty. Someone, usually HR, can ask the candidate about the problem and hear their story. See if there are mitigating circumstances or if the information received was incorrect. If they claim that the information in the report is inaccurate, then the candidate needs to work directly with the agency to correct it.
If what turned up was correct and unambiguous, then the organization faces a decision. Some things are going to clear showstoppers , such as the following:
Dishonesty, such as any falsified information on any of their provided information.
All fraud, including (but not limited to) payment card/check fraud, embezzlement, fraudulent trading, forgery, counterfeiting, money laundering
Any computer crime
Economic/corporate/business/industrial espionage, which can turn up as a civil lawsuit as well as criminal
Bribery, corruption, extortion
Theft, burglary, possession of stolen property
Felonies, terrorism, drug trafficking, crimes against persons
Producing, supplying, importing, or trafficking controlled drugs/substances
If a candidate doesn’t have any of these problems, there is a possibility for appeal and review. Remember what is uncovered during this check should be used as part of a risk analysis. Given the information and their explanation, HR, the hiring manager, and someone from the security department can discuss the risk. You don’t need a large committee for this; a single person from each represented department is sufficient. When looking at the issue, you can consider the age, the magnitude, and the relevance of the incident to the proposed position. Decisions should be documented and kept private within the HR department.
Employment Agreements
It’s likely the organization has many terms and conditions of employment, not just counting the ones imposed by the security department. It’s common for the HR department to ensure that all the relevant policies and agreements are presented and explained to the candidate. HR usually is also responsible for making sure the person signs off on these documents and has copies available. The following are the major agreements and policies that you want the candidate to agree to:
Legal non-disclosure agreement (usually drafted by the legal department)
Proprietary information and inventions agreement (usually drafted by legal to protect ownership of intellectual property developed while employed)
Security policy (the high-level organization-wide policy)
Acceptable Usage Agreement
These are the common minimum documents. Some organizations also throw in a code of ethics, sexual harassment/anti-discrimination policies, and even the employee handbook for the candidate to review and sign.
Rather than present people with mountains of paper and track ink signatures, some organizations use electronic distribution systems to push out these documents and capture approval. Some electronic signature systems require employees already have internal network access, which means they’re already online before agreeing to follow policy. In those cases, someone needs to be assigned to be responsible for ensuring that they are all approved in a timely manner. If they are not, then that person’s access credentials should be revoked and their supervisor notified.
Security Training
The content and goals of security awareness training were covered in Chapter 10. The actual rollout of the training can be done in a variety of ways. Some organization’s schedule annual in-person classes that all employees are required to attend. Some organizations do this via online live or pre-recorded broadcast. Some even create or contract out computer-mediated training sessions. Responsibility for providing the training can be split with the HR department, who can be responsible for scheduling and delivering the training. The security group should always be responsible for the content. As everything else discussed here, security training should be a mandatory requirement for a user gaining access to sensitive systems. Other methods of security awareness are available as well. This can include the following:
Security awareness quizzes
Security brown-bag meetings or training videos on other security topics
E-mailed or intranet-published newsletters and security warnings
Office posters and banners with security tips
Reminder cards left on people’s desks for bad/good security behavior (“Please lock your workstation when you leave.”)
Periodic incentive awards for good security behavior (cookies at the security brown bag session)
These kinds of things should be seen as complements to the main security training, not replacements.
In addition to basic security awareness training, the HR department should ensure that individuals with security responsibilities are qualified and properly trained for their roles. Since security threats and technology change frequently, this can mean continuing education for staff. Staff members who hold professional certifications are already required to maintain educational credits to keep their certifications. The organization can work to support this by subsidizing some or all of their training and certification costs. New controls and tools should also entail technical training for the operators and implementers. This doesn’t mean that you have to send the entire network-engineering department off to weeks of firewall training, but sending one or two is prudent, especially if a new system is being brought online. Records of all this training should be kept and tracked.
Sanctions for Policy Violations
When individuals violate security policy, there needs to be consequences. The obvious consequence is termination, which may be warranted in some cases. However, in some situations and venues, this may not be possible. This is an area where you can get creative. The goal should not to be punitive, but instead to ensure that this never happens again. If you do terminate someone, then consider making public the reason for the termination for deterrence effect.
If the violation was accidental, then the consequences can be as simple as a reminder or additional security awareness training. In the past, I have sent repeat offenders to “security traffic school” for additional and more detailed security training. The behavior could have been accidental or a one-off, or it could be a chronic problem. Be sure to calibrate the sanction response based on that.
When addressing violations, it is best to be clear and open in your discussions with the offender, and focus on the tangible observed behavior. For example, you can say something like, “I have been informed that you have violated X policy.” Then you state the policy before continuing with, “This may have been an accident or your intentions were good, however this does violate our policy. We need to make sure that this will not happen again.” You should explain the reason for the policy and the consequences that can occur if it is ignored (the least of which is an audit finding all the way up to a security incident).
Sometimes people raise objections, such as the fact that other people are violating this same policy. Here you should redirect them back to the violation being discussed with statements like, “That may be true and we will deal with that but we are talking about your policy violation right now. Can you confirm that this will not happen again?” The organization should always keep a record of the incident so you can see if this is a chronic problem or a pattern of behavior.
In situations where termination is not possible due to union or legal constraints, then revoking or reducing access privileges can reduce the threat significantly. It also sends a strong message regarding the unacceptable behavior.
In cases where security policy violations also overlap with criminal violations, the organization should strongly consider turning the matter over to law enforcement authorities. The following are some of the situations in which law enforcement should be contacted:
Child pornography
Threats of violence
Stalking or harassment
Hacking or espionage of others outside of the organization
Depending on the stance of the acceptable usage policy, the organization could also be in a position to turn over digital evidence to the authorities without a warrant. In these cases, the security department should oversee the secure collection of the evidence and protect it from tampering. We’ll cover this in depth in Chapter 20, which focuses on response controls.
Managing the Insider Threat
During the risk analysis, we looked closely at the large threat of malicious insiders . Because of this risk, access for trusted users must be controlled. A wide variety of controls and tools can be brought to bear. However, like all risks, insider risk can never be reduced to zero. As long as you allow humans in the loop, you have to trust them to do their jobs correctly at some level. Let’s break down these controls.
Monitoring
Strong oversight is a both a good detective control as well as a preventive control as a deterrent factor. You should have video surveillance monitoring in place in all your key secure areas. Recording all entries and exits from the server room can help spot suspicious after-hours behavior. Monitoring on administrative access and actions is absolutely necessary on systems holding confidential data. There are a number of logging tools built into most operating systems that record administrative actions. In addition to the built-in tools, many commercial products and add-ons are available to enhance the recording, analysis, and reporting on those actions. The monitoring records should be held in a tamper-proof system that is separated from the usual administrative systems. This can mean parallel systems that are managed solely by security with either no or read-only access by the IT department. You do not want people removing the records of their own misdeeds. Logging is discussed more in Chapter 20.
Least Privilege
A simple way to reduce the risk of insider abuse is to reduce the number of people who have access. It sounds trivial but I have seen some organizations where half the company has full administrative rights because of poor architecture. Out of the population of all users, the percentage of system administrators should be a single digit. If more than 10% of your users have admin rights, you will have problems. The concept of least privilege means to give only the least amount of access that people need to do their jobs and not an inch more. Not only will you be reducing the quantity of threats, but also lower numbers of privileged users mean less work in oversight and monitoring. If you have 30 system administrators, then you’re going to need several full-time personnel to just to review the access logs in a timely manner.
Strong User Management
We’ve already discussed the key pieces of this earlier in this chapter, but having robust processes around user provisioning and termination really reduces insider access. Insiders sometimes create their own shadow accounts or elevate their privileges in order to commit their crimes. Having strong accountability and monitoring around user rights can nip that in the bud. Watch out, sometimes user rights can slowly add up as they change jobs throughout an organization. If someone leaves a department to go to another, remember least privilege and remove all of their rights, and then add back in what is needed for the new role. I’ve seen people transfer in and out of sensitive positions but retain their old rights. With accountability and monitoring comes the mandate for unique accounts. There should be no shared accounts for sensitive work. If there needs to be sharing of accounts because of technical limitations, there needs to tight monitoring and oversight on their use. One rule I’ve used is that every time admins used a generic root login on a server, they had to register the event in a help desk ticket so it could be tracked to them individually. Unlogged root accesses were investigated as security incidents when discovered in the audit logs.
Segregation of Duties
In the financial accounting realm, segregation of duties is a powerful tool to limit privileged access. It means to design systems so that the cooperation of two or more people is needed to perform certain tasks. Think of it as the two keys needed to launch nuclear missiles rule that you see in movies. It can also mean structuring processes so that one role is designed to act as a control over another. This is why you should set up IT administrative logging to separate from normal IT systems, while also limiting the access of those who do the monitoring over IT systems. Another common segregation of duty control is to separate code development and live systems. The programmers who make changes to source code are not allowed to deploy changes to production systems. Furthermore, system administrators are not allowed to make changes to source code. This provides a check and balance to how production systems function. Both of these forms of segregation of duties are an important part of change control as discussed in Chapter 13, which focuses on administrative controls.
For those working in DevOps environments, segregation of duties regarding deployments and source code can be challenging. In a DevOps environment, developers are empowered to push their own changes into production. Furthermore, IT operations personnel are encouraged to write code. In these cases, you can use automation and logging to take over deployment and change tracking. In DevOps, all code changes should be automatically checked, logged in detail, and have the capability for rapid reversal. Overall, the guidelines for segregation of duties are to segregate requests from approvals and to segregate work operations from work records.
Know Your User
In banking, there is a control called know your customerthat instructs bankers to verify the identity and intentions of their clients. Regulators are leveraging bankers to spot bribery and money laundering operations. That same principle can work with spotting potential malicious insiders. This does not necessarily mean copious logging of all user actions and alerting on anomalous activity. There are simpler and more direct methods to do this.
One is to encourage and train managers to pay the proper amount of attention to their staff. This means ongoing, weekly one-on-one meetings to track their progress and attitudes. It can also mean having a culture of transparency, where open discussion of issues and concerns are shared. While these two things are often not in the purview of the security department to control, they can be suggested as good management and security techniques to upper management.
In addition, security awareness training should coach employees to report suspicious behavior. The mechanism for reporting should also be designed so that notifications go to multiple persons, spread between groups. In some organizations, I have seen a generic report_incidents e-mail address that goes to the entire ISMS committee used. This way the person reporting doesn’t risk their message being ignored, deleted, or covered up by a single person. In other organizations, the help-desk ticketing system is used to track incidents.
Filtering
Technical controls that monitor and filter data stores and transmissions can be useful tools to prevent accidental and some malicious copying of confidential data. These tools are often called DLP for data/digital loss/leak prevention (no one seems to agree on what the acronym stands for) and can work with e-mail, file shares, local workstations, and even USB ports. They scan for known confidential data signatures, such as credit card numbers or social security numbers. You can usually program in new signatures based on the unique confidential data types or watermarks used in your organization. When detected, the DLP can block, sound an alarm, or automatically encrypt the data before something unfortunate happens. Like most signature-based technical controls, DLP is not very accurate and can usually be fooled by a skilled attacker. Some DLP solutions also create a lot of false positive alarms as lots of innocent things can look like confidential data. They can also get rather expensive in terms of both software cost and performance drain. As people can make mistakes or worse, act maliciously, a DLP filtering system can help reduce the risk of confidential data exposure.
Processes, Not Individuals
With risks involving people, there is a human tendency to focus on specific individuals. Billy in accounting is somewhat shifty and he’s always working late. Maybe he’s up to something. Eric the database administrator is always commenting about how the government is invading our privacy and trying to take away our firearms. Tina the web designer is so quiet and never talks to anyone. What is she hiding? However, security professionals should worry more about failed or missing processes, not about specific suspicious individuals. Don’t be distracted by your biases and neglect maintaining the controls you have in place. Work on aligning processes and building strong controls, and you will be on the right path to reducing the risk from people.