Yesterday, it was announced that the Chief Information Security Officer of Equifax, Susan Mauldin, had retired (

This is the person who was responsible for the security of 143M American’s financial records. And this doesn’t even count the number of British and Canadian records that were compromised.
And, 2 months after the security breach was discovered she was allowed to retire.

If Equifax really cared about the damage she, and her greoup, has done they would have fired her, with cause, back in July or early August.

And this doesn’t even take into consideration her questionable background.

What does it look like when she has BA and MFA degrees in Music Composition from the University of Georgia? I’m not saying that she might not be a genius. She might even have the capacity to become an expert on computer security and manage the sensitive financial security needs of most of the people in the U.S. However, as a public company with so much at stake, couldn’t Equifax have hired someone who has done nothing but live and breathe security for their entire career and has a Computer Science background?

In addition, someone is doing a pretty good job of scrubbing the web of her background. First, her Linkedin profile was renamed and changed, now it has disappeared completely. Below is what it was before getting deleted.

Mauldin Linkedin Profile

Why does it list her titles as merely ‘Professional’? What is she trying to hide?

You can’t find anywhere on the web what she did immediately after earning that MFA in Music Composition. In particular, what did she do to be able to earn the position of Senior Director of Information Security, Audit and Compliance for Hewlett-Packard’s outsourcing practice from 2002 to 2007 which seems to be the springboard into the eventual position of CISO at Equifax? What was she Group Vice President for at Sun Trust Banks? Her background has been very carefully crafted and sanitized. Think about that. Most people want you to know what their background and experience are. ITtappears that she doesn’t want you to know.

This breach is going to cause irreparable financial harm to millions of people and the economy, caused by someone who may not have been qualified to be in her job.

Let’s hope this is a wake-up call to the government and financial industry to fundamentally change the system and develop something more secure with tighter security and restrictions on what information companies can retain and store.

In the meantime, Equifax needs to go the same path as Enron – into oblivion. If not merely for the fact that their lax security will result in most people in the US worrying about their credit and finances for a long time to come, but also for the fact that they allowed her to gently retire instead of rapidly firing her for cause.

In reality, the weakest link in password security is the user. From weak passwords, to passwords that can be inferred (think birthday, spouse or children’s names), to sticky notes left on screens, to susceptibility to social engineering – in many cases, it is easier for hackers to obtain system passwords directly from the user rather than some type of hack.

Unfortunately, no matter what you do from a system perspective you need to continually educate and remind your users of their responsibilities and to be on the lookout for the various means that could be used to obtain system passwords.

Social Engineering is a common tactic because it is easy to exploit since it is human nature to trust. Common types of social engineering include:

• Phishing attempts where some type of communications appears to come from a legitimate source such as a business or institution. Phishing attempts many times ask for help, ask you to verify information or notify you that you are a winner of some sort an get you to divulge personal information that can be used by the hacker.
• Response to a question that you never asked. In this scenario what appears to be a legitimate business that you use responds to a question you did not ask. When you respond your authentication is subsequently used by the scammer.
• Free or too good to be true offers. Free downloads may be infected with malicious software that can cause more harm or your payments never result in a delivered product.
• Email from a friend whose account has been hacked. A link or download in this email can infect your machine with malware potentially giving access to everything on it to the hacker.
• Hackers just ask! In a very simplistic approach hackers will merely call a user and tell her some story for which they need a password and/or personal information. Again, trusting the caller, the user gives the hacker all the information they need.

There are other common techniques including:

• Shoulder Surfing – looking over a user’s shoulder or reading sticky notes attached to the user’s monitor
• Inference – Using personal information such as family names or birth dates to guess passwords

The user is usually the weakest link in any system security. Train your users to spot attacks and respond appropriately.

Securing Server Access

August 15th, 2016

With the wide availability of access to servers for startups, it can be easy to skip some very important steps in planning for and implementing server security.

In an earlier post, I talked about password strength. However, even with the strongest password there is always the chance that it could be guessed on the first attempt. Therefore, it is imperative that admin access to servers be secured more thoroughly. Usually, this is done through the use of Multi-factor authentication (MFA). Wikipedia, defines Multi-factor authentication as:
Multi-factor authentication (MFA) is a method of computer access control in which a user is granted access only after successfully presenting several separate pieces of evidence to an authentication mechanism – typically at least two of the following categories: knowledge (something they know), possession (something they have), and inherence (something they are).

For Cloud computing, MFA usually boils down to something you know and something you have.

Many Cloud providers include the use of public key SSH authentication as part of the server setup. This involves using a public and private key. However, using this basic method is only as secure as the device on which the private key is stored. Therefore to implement MFA you need to generate the SSH keys with a strong passphrase. In this case, you can only access the server with something you have (the private key usually stored on a device) and something you know – a strong passphrase). The key here is to always generate the SSH keys with a passphrase.

Another method gaining acceptance is to use something similar to Google Authenticator (Note: I will use Google Authenticator as a generic term for an application that uses a Time-based One-time Password (TOTP)). Google Authenticator makes available a 6- to 8- digit password that is essentially a shared secret between the user and the server that changes every 30 seconds or so.

The user logs in using a strong password and is then asked for the Google Authenticator shared secret. The user can only access the server with something they have (the Authenticator generated shared secret) and something they know – the strong password. Again, since the device on which Google Authenticator runs (usually a smart phone) can be lost, it is essential that a strong password is also used.

Finally, as an added security measure for admin server access in the cloud it is a very good idea to restrict SSH access (port 22) to just the ip range of your administrators.

The bottom line is that you need to secure server access with more than just a strong password. MFA and ip restricted access go a long way in achieving that.