The people aspect of security

I have seen, in my life, many more security problems caused by humans than machines. With the people aspect of security I mean all human actions that can increase or decrease security. Humans are in the vast majority of company processes, and can often be the weak link of the chain in multiple occasions, such as in the following examples:

• A system administrator disables a firewall (or allows all by default) to speed up a process
• A system administrator sends a PEM certificate/PGP private key by e-mail
• A user creates a weak password to remember it better
• A user writes his password on a piece of paper stitched to the monitor
• A user gives his password to a colleague via his phone

As you can see, there are some actions that are committed by system administrators, while others are committed by users, but at the end of the day, they can have a huge impact no matter who committed it. Some of these actions can be prevented using automatic systems, such as using a password grader before accepting a password. Some other actions can be prevented only informing your users and system administrators and teaching them to act properly for your company security and their own.

I divide the human aspect of security in the following categories:

• Simple forgetfulness
• Shortcuts
• Human error
• Lack of information
• Social engineering
• Malicious actions under threats
• Malicious actions for own advantage

Simple forgetfulness

This is a very common pattern in humans. Very often, people perform actions without really caring or not thinking about the consequences of their actions. The most commons cases in this category are:

• A user creates a weak password to remember it better
• A user writes his password on a piece of paper stitched to the monitor
• A user gives his password to a colleague via his phone

As you can see, I have listed only user actions, because very often those errors are committed by users, not system administrators. The good news for you is that these kinds of errors are usually easy to spot, fix, and prevent.

I have worked in a company that needed to increase its security, so we started working on this because is very cost effective. We started assessing the passwords using John the Ripper in a secure machine on the hashed passwords. The result was shocking—more than 95 percent of the passwords were found in less than an hour on an average computer. We decided to create a very small course (2 hours) in which we explained how to create safe passwords and how to handle them safely. The course has been forced to all employees in the following week. After the week ended, we created a JavaScript, was been loaded on any login page, which checked whether the password in its current form was secure enough, and if not, changed the reference URL of the login button so that the first page proposed to the user was the change password page. After one week, we ran the John the Ripper test again and with much joy we have seen that the first password has been found after more than 24 hours in the test and in 24 hours we were still under the 1 percent of passwords found. The policies we enforced were the following:

• No dictionary word
• At least one uppercase letter, one lowercase letter, one number and a special character, excluding '!', '#', '@', '&', and '$' which are the most common special characters
• At least thirteen character-long passwords

Using these three rules, we removed the weak passwords problem, reaching 80 bits of entropy on each password.

Note

The National Institute of Standards and Technology (NIST) suggested to use at least 80 bits of entropy for secure passwords.

To be sure that the people followed the instructions given during the password course to manage the passwords, we identified a few people in the company who were most successful during the course, to help out with looking for colleagues that were handling the passwords unsafely. Those people caught handling unsafe passwords were signed up for another course (4 hours, this time), which was more focused on giving the reasons as to why people should follow the rules, rather than simply teaching them the rules (that were already discussed in the previous course).

As for password sharing and other similar practices, a system has been put in place to be sure that no more than an IP could use a certain username and password at a given moment in time. If more than a user did connect, the account was locked automatically and the user (owner of the account) had to call the IT department directly to ask them to unlock his account. In a few months, these kind of actions will no longer happen. We did not solve the password over telephone problem directly (because is not possible to enforce this kind of rule, unless there is someone listening for all phone calls, which is pretty impossible), but we have made it pretty noticeable by the IT department.

Shortcuts

People are lazy and will try to use any possible shortcut that they can think of. I know this is a huge generalization, but it's true more often than not. If you ask people to do a complex process and they see the possibility of having similar results with a much simpler process, the majority of them will use the simpler process and this is more true, when the same person has to do the same process multiple times.

How can you defend your company from this? The first thing to do is to keep the processes as simple as possible, so that people have less advantages to take a shortcut. The second thing to do is to inform all the people that are part of each process the reasons why that process is done in that way and what can be the consequences of a different process.

To explain this at best, I'd like to bring you a very famous example from a different field, aviation. British Airways Flight 5390 became famous because on June 10, 1990, since an windscreen blew due to a panel that was improperly installed. In the process, the captain of the plain, Tim Lancaster, was ejected halfway out of the aircraft. The body of the captain (still alive) was firmly pressed against the window frame where it stayed until the first officer managed to perform an emergency landing in Southampton with no loss of life.

The reason this accident is of such importance is that it shows what can happen when enough information about a process is given to the people who are executing that process. In this case, the problem was that in a replacement done few hours before the flight, the windscreen had been changed and wrong bolts were used. In fact, 84 of the 90 windscreen retention bolts were 0.026 inches (0.66 mm), which is too short in diameter, while the remaining six were 0.1 inches (2.5 mm), too short. This has been possible because the operator that changed the windscreen used a like for like method to select the new bolts, instead of looking up on the maintenance documentation, even if this would have been the right procedure following the official British Airways policies, which required referencing to the maintenance documentation for each component that is being replaced on the planes.

Three out of the five recommendations of the Civil Aviation Authority following this accident, aimed to improve the probability of the right execution of the procedures by the people, mainly through training, and testing including the possible consequences of shortcuts during the processes. The remaining two recommendations were about examining the continued viability of self-certification with regards to safety critical tasks on aircraft and about recognizing the need for the use of corrective glasses, if prescribed, in association with aircraft engineering tasks.

Human error

Human errors are very frequent and usually have disastrous consequences. One of the main causes of human errors in IT, in my experience, is pressure.

Human error implies that the person doing the action knows what he/she should do, but does it differently because there are external factors acting on them, such as pressure or tiredness.

I have not seen a single office in my life that was not susceptible to pressure or tiredness—obviously a good management can help, but cannot prevent it. What you can do is document everything when you are calm and rested, so when pressure or tiredness grow, it is possible to follow the documentation.

I have seen this in multiple companies' IT departments with no documentation. I know this is pretty common (at least in south Europe) because multiple colleagues of mine have told me that they have had similar experiences. I do remember a specific case in which I went to a company to create an active-active cluster.

Note

In my experience, the presence of documentation for certain procedures creates less pressure on the executors; therefore, the simple fact of having a procedure can decrease one of the cause of errors.

After a few days in the job, the main MySQL database went down and the manager asked me to fix it. After a little bit of analysis, I had in place a workaround promoting the slave to the master, so that the company was able to work again. This was obviously a dirty workaround that had to be fixed very soon. So, after working for hours, when it was safe to shut down the system for enough time, we created a new slave to restore the initial situation. I have asked the manager if this ever happened before and how they fixed it the previous times. He responded saying that it already happened few times, but the person who fixed it the previous time left the company months ago leaving no documentation, since the company never forced him to write it. Having all data on a SAN, we chose to do a SAN copy to improve the speed of the recovery. The result has been a huge mess with doubled LVM IDs that required more than 2 hours to be cleared.

Obviously, I cannot blame the previous technician for the LVM issue, but if he/she would have written a documentation for that procedure, we would have followed it without creating the mess, considering that all that mess happened because a single LVM command had been forgotten planning the work.

Lack of information

As we have seen, human errors and shortcuts are often caused by a lack of information. Sometimes, the lack of information does not result in human errors or shortcuts, but ends up in disasters because the person that is doing the procedure does not know something relevant to the procedure, or has no real idea about the environment it is working on.

The solution is to create the documentation and to update it constantly. Obviously, it is important to read all the documentation too. In my experience, it is really important to have a good tool for documentation. Some companies use Word documents or similar kind of programs. I think this is wrong for mainly the following four reasons:

• Word processors mix style with the content, which can create problems when you have commands and code in your documentation
• It's not possible, or very hard, to link each document or section. Every time a system or procedure is mentioned, it will be linked. Each system should have a page with all procedures and configuration linked, and vice versa.
• It requires specific software or other kind of not-so-friendly interfaces (such as Google Drive)
• It does not support (or supports small) versioning

I think the best way to provide documentation is with a wiki installation or a Git repository containing human readable documentation in a markdown or a similar format. If you go for the Git repository option, remember to export them in HTML too, to be more accessible. In either case, remember to backup your documentation frequently because it's a very important asset.

Tip

Always create a documentation of everything you do, because later on you or someone else will need it.

Social engineering

"The information security industry defines social engineering as an attack that breaches an organization's security defenses by manipulating people and the human tendency to trust."—SysAdmin Audit Networking and Security Institute (SANS Institute)

Humans are in pretty much all processes or can enter into them if they feel the urgency to do so. Humans, also, are very often the weakest link of a security chain since they are flexible, while computers are not.

Tip

Humans are flexible and usually try to meet other people's expectations, often accepting a rule violation to do so.

Today, it's possible to create a secure system for a small amount of money that will require multiple times more money to break into it. This is the reason why attackers use people inside the company to drastically reduce the amount of effort needed to break into the system. The majority of times, the attacker exploits the employee's willingness to meet the other person's expectation to get the information they need.

Lately, social engineering has been split into tens of fields based on the vehicle of attack and the goal. We will not go deeper in this topic at the moment.

I would like to bring you an example of social engineering I did, because I didn't believe what happened would have been so easy in that company.

I was placed in a big company to help them increase their security. The manager was willing to undertake a lot of actions in this sense, but thought that social engineering was only a commercial thing used by sellers to sell more useless services and therefore was not willing to implement any social engineering countermeasure. To demonstrate to him the importance of social engineering countermeasures, I pulled out my phone, and called the company front desk hiding my number. I informed the person who responded that I had problems with an invoice calculation, and therefore had to speak with someone in the accounting department. Soon after a person of the accounting department responded. I informed him that I was calling from Microsoft helpdesk and that I had to do some tests with him due to a new update that has been rolled out that morning. The man was really happy about my call because he also had a problem with a scanner that was not able to make it work properly. I said that a part of the procedure required his company password and a lot of other data to verify that everything worked. The incredible part was that he gave me all the information without doubting my intentions. While I was on the phone, the manager was shocked that an employee had shared so much information with an unknown person over the phone.

Evil actions under threats

Sometimes the attacker is not able to circumvent anyone in the company, so he/she might want to identify a person who has enough clearance and is easy to threaten to obtain what we are looking for. In movies, usually, the villain kidnaps a person from the hero's family to obtain what he is looking for. Luckily, in reality, this is not common and usually the threats are much smaller, but still work for the attacker's purpose.

My point of view is that it is really important that the company works to ensure their employees work in a secure environment mainly limiting their powers. Mistreating someone is very dangerous and legally speaking very bad in the majority of countries; therefore, the attacker would like to get a single person with enough power, but if there are no people with this power, an attacker could try different approaches to the problem leaving aside the employees.

Evil actions for personal advantage

I have left this category as the last one because it's often hard to accept, mainly in small companies, and very hard to deal with.

Sometimes people commit evil actions and you have to be prepared for this. This kind of inside attack is usually very dangerous because they will be able to ask for favors from their colleagues with legitimacy. If they do not have direct access to the resource they need, they can use social engineering but using their real credentials to gain more trust and to be able to ask for bigger favors or more confidential information.

For this reason, you have to segment the process and have very strict rules that don't allow a person to know more than they are meant to know. Also, it is important to inform your employees and make them aware of this kind of risk.