Art of Information Security

I was recently  in New York for a two-day briefing on emerging technologies from a key technology partner. During the morning session the presenter asked a number of questions of the room as he worked through his deck.

At one point he asked: “Who likes their Information Security guy ?”

I raised my hand, to which he quipped: “Well, they aren’t doing their job then!”

To which I quipped: “Actually, I do my job quite well.”

Stereotypes…

In ancient times, skillful warriors first made themselves invincible,

and then watched for vulnerability in their opponents…

- “Formation”, Art of War, Sun Tzu, 6th century B.C.

The core of Information Security is Risk Management. The pursuit isn’t an “invincible” password policy, but one that provides reasonable protection against known threats. The goal is often not an “invincible” application, but one which is hardened appropriately and also still usable.

But all too often, many practitioners jump right to NO – I WON’T ALLOW IT. this leap is made without understanding the whole of the problem, or the real risks that are specific to the situation.

Now, there are folks in Information Security (and HR, accounting, etc.) who have to say NO because corporate policy, procedure, etc. require them to. This is really not the case that I am exploring here. Here, I want to focus on the role of the Information Security Architect, Consultant, Vulnerability Manager, Risk Manager, CISO, etc. when they are working with the business and IT partners.

Solid Risk Management requires a partnership between the folks who are the Subject Matter Experts in the risk space, and the folks who have a business or organizational need that must be met.  The right or proper answer often isn’t the Black-and-White “We never allow X” (sometimes it is ), but generally “We usually avoid X, due to these risks, but in this case we can compensate by applying these additional controls” or “We usually don’t permit X, but in this situation it isn’t problematic due to Y”.

I spent a lot of 2007 learning this lesson.

This lesson was taking hold enough that I started researching some of the business literature on this topic. It was then that I ran into Organizational Consulting: How to Be an Effective Internal Change Agent by Alan Weiss, and this definition on page 4:

Organizational Consultants are basically advisers to management who must provide objective, pragmatic, and honest advice to their clients. If there is a trusting relationship, then the clients will always be confident that their best interests are being served, no matter how threatening, contrarian, or painful that advice may be.

 Organizational Consulting is a book on becoming an effective internal change agent. In a way, when I am acting in an Information Security (Architect, Consultant, Advisor, fill in the blank…) role, I see myself being responsible for not just managing the risk issue at hand, but engaging my IT/LOB/etc in such that they can understand why and how the final state came to be.

So, let’s paraphrase Alan’s definition some…

Information Security Consultants are basically advisors to Information Technology and Line of Business partners who must provide objective, pragmatic, and honest advice to their clients, with the objective of managing risk for the benefit of the organization as a whole.

If there is a trusting relationship, then the clients will always be confident that their best interests are being served, no matter how threatening, contrarian, or painful that advice may be.

It has been my experience that when I take the time to…

• Listen and demonstrate genuine interest in the business problem at hand
• Educate the key players about the risks that various approaches contain
• Make those risks tangible, using examples and data when available
• Work with them, not against them

…that my success rate is very high ! “Success” being defined as both getting the Information Security risks managed, getting the underlying business need met, and being re-engaged pro-actively by the people I worked with the next time around.

Of course, all of these are relationship-building behaviors. All to often, relationship-building is thought of as lunches and golf games, neither of which I do much of. Relationship building is about how you treat people when you are working with them. No one cares that you played golf with them once if you won’t help them solve the problem at hand. Helping them find a way to meet their business needs risk appropriately builds relationships.

Of course, saying NO is a lot less work… for a while….

Cheers, Erik

( If you enjoyed this, check out more Professional Development on AoIS )

A colleague and I are co-presenting at the Central Ohio ISSA chapter on Wednesday morning…

Information Security Awareness Raising – A Example to Critique and Discussion

The aim of this presentation is to provide ISSA attendees with fresh ideas, for increasing the awareness of Information Security issues with their internal customers and partners. The presentation will have two parts. In the first part Justin and Erik will present a Information Security Awareness Presentation which is targeted at an audience of business and IT partners. 

During the second part of the presentation, preliminary information regarding the vital role of Information Security Awareness Raising will be discussed. After this initial introduction, everyone will be asked to participate in a dialog discussing if the materials were or were not effective Awareness Raising materials and to share their experiences and insights.

If you read this post, and then attended the presentation – please let me know. (This will be my tip off that highly un-likely events are occurring in my world, and that I should purchase a lottery ticket… )

Cheers, Erik

My apologies for this “phantom” posting… “Pro Dev: Who are We? What is Our Role?”

While editing that posting, I published it way prematurely. (Can you say miss-click?)  Now, I corrected this within minutes, but due the magic of Google and Feedburner that fragment was whisked onto the net (and perhaps will live forever… )

Now, you would think that you could just delete the post, and all would be well – Wrong !

So, that fragment (which was on-line for less than 3 min), was cached into the google reader and other blog aggregators, and has (embarrassingly) set a record for views in the first 24 hours. 

The good news is that it looks the like Professional Development series I have planned for AoIS is going to be a hit ! The bad news is I need to find a WordPress plugin that asks for a “are you sure” idiot confirmation on the publish button…

BTW, It appears that 2009 will be the year of the series on AoIS. Currently in the pipeline are:

• The Secure Your Linux Host Series
• Professional Development Series
• Cryptographic Controls Series 
• Interviews with Infomation Security, Risk Management, and Privacy Luminaries !

I hope to have at least one installment for all of these series posted by the end of January.

Again, my appologies for the draft fragment – the actual posting (Part 1 in the Professional Development series) is being proofed and should be up in a few days.

Cheers, Erik

In Secure Your Linux Host – Part 1 I recommended using Log Watch to keep an eye on what may be happening with your host. Well, today’s review of my own Log Watch indicates that I am being probed for phpMyAdmin. (Someone wants to abuse my database…)

Here is a sample from the log:

401 Unauthorized
/admin/mysql/main.php: 1 Time(s)
/admin/php-my-admin/main.php: 1 Time(s)
/admin/php-myadmin/main.php: 1 Time(s)
/admin/phpMyAdmin-2.2.3/main.php: 1 Time(s)
/admin/phpMyAdmin-2.2.6/main.php: 1 Time(s)
/admin/phpMyAdmin-2.5.1/main.php: 1 Time(s)
/admin/phpMyAdmin-2.5.4/main.php: 1 Time(s)
/admin/phpMyAdmin-2.5.5-pl1/main.php: 1 Time(s)
/admin/phpMyAdmin-2.5.5-rc1/main.php: 1 Time(s)
/admin/phpMyAdmin-2.5.5-rc2/main.php: 1 Time(s)
/admin/phpMyAdmin-2.5.5/main.php: 1 Time(s)
/admin/phpMyAdmin-2.5.6-rc1/main.php: 1 Time(s)

Now I have seen activity like this before, but I thought this provided a good example of the increased awareness that scanning through the Log Watch report can provide.

This also provides some solid data in support of having some other controls in place if you are in fact running phpMyAdmin (or even MySQL). Most of the time the passwords that are used to access the content of databases are not used by humans – they are stored in the properties files of the applications that are using the database.

Ok, So Your Logs are Letting You Know What is Being Probed, Now What ?

This awareness allows you to make sure that you are adequately protecting that which is being attacked.  In this case, I already have controls in place to manage this risk. Let’s discuss them.

Lock Down Web Access to Administrative Tools

phpMyAdmin (usually) requires a password (more on that in a second), but you can also add an additional layer of security to your web-based administrative services by adding authentication at the http server itself.

Apache has a nice tutorial: Authentication, Authorization and Access Control

If you run web-based administrative tools, you may wish to lock down the web paths that contain them. In addition to providing a first line of defense, this will reduce the information available to attackers during the reconnaissance portion of their attacks.

If you lock down “mywebsite.com/admin” as described in the Apache How-To above, and you have additional directories under this “mywebsite.com/admin/phpMyAdmin” and “mywebsite.com/admin/keys2Kingdom” , they will not be visible to the attacker (until they guess the password…).

Confirm Strong Passwords

Functional IDs (also called service accounts) are used for application to application (e.g. wordpress to MySQL) authentication, and are (and should be) only handled by humans during installation and maintenance activities. Functional IDs should be long, very random, and not contain words or memorable substrings. (Functional accounts often do not have password retry limits, which heightens the importance of the strength of the password.)

I sometimes use the GRC Strong Password Generator (ah yeah, my ow site gotentropy.artofinfosec.com is down right now…). You can also generate strong passwords using openSSL from the Linux command line:

openssl rand -base64 60

In both cases I prefer to cut and paste a long substring of 40 to 50 characters  (dropping a few characters off both ends, especially the “==” base64 termination marker from the openssl command), and then adding a few characters of my own.

Now, I would never expect an application user to type a 40+ character password. But for a Functional ID – why not ? The root MySql and all db user’s ID should be very complex and long, especially if the host is internet accessible. (If you are using phpMyAdmin, it has a very good password generator included in the “Add User” functionality.)

We will be discussing other ways to protect password based systems from remote attacks in “Secure Your Linux Host – Part 2″… Out soon…

Cheers, Erik

( Part of the Secure Your Linux Host series…)

Bot-net masters, phishers, spammers, hackers, etc., all need insecure hosts on the internet that they can find, break into, and bend to their will. I was in a meeting one day with a very frustrated retail banking executive who wanted to know who was providing all of the computers, all over the globe, to the phishing and spamming teams that were attacking his bank’s on-line services. The bad news that I had to give him was that the root causes of the problem were people not taking security basics seriously – basics like patching their systems promptly, and using strong passwords.

The most shocking statistics that come up over and over again in the Information Security and Risk Management research:

• 75% of Data Loss events involve an insider
• 75% of the insider’s actions were negligent and not self-serving or malicious

This means that over half (56%) of Data Loss events would not have been but for incompetent or naive personnel.

As an Information Security professional, I have no delusions that the internet underground is going to someday run out of computers susceptible to the script kiddie attacks that are dependent on weak security practices, but I do believe you can protect your host – if you choose to. So I decided to kick off this series on AoIS, from one Linux enthusiast to another. Oh, and FYI, currently I am running Ubuntu as my ‘distribution of the moment’.

Foundations

The low-hanging fruit in securing your host is all pretty basic stuff. Here is the list:

• Set the root password to something very long and complex
• Forbid remote access to root (Part 2 will cover this for ssh)
• Update and patch your host early and often
• Set-up Mail Transfer Agent (MTA), and forward root’s email…
• Install Log Watch

Complex Root Passwords

Ok – you would think that this has been beaten into the ground, but the data shows that there are lots of systems which (1) allow remote root access and (2) aren’t using very hard-to-guess passwords.

• Set a long and complex password
• Stay tuned for properly secured remote access with SSH (part 2)

Of course, this should include not just root but also accounts with root-like privileges (e.g., can run sudo). Many attacks on privileged accounts make assumptions about account names. Set up a personalized account on the host, and then grant sudo privileges.  (Oh, and “admin” is a great name for that account, but your name will work just fine. It seems that the attack scripts don’t yet troll the public information about the box for names yet…)

Early and often?

The first thing I do after I install and boot a new host is update it.

# apt-get update
# apt-get upgrade

No brainer there…

I use the following variation in a Cron job to regularly update all of the packages on the box. There are a few tutorials on applying only the security patches, but I choose to go ahead and update all packages.

su --login --command 'apt-get update -qq; apt-get upgrade -q -y; exit'

The -q and -qq flags suppress messages, shortening the output. The Cron facility will automatically  forward that output to the root user.  The -y option tells apt-get to assume a Yes answer for any of the questions.

The “su –login –command” provides context to the command so that it can operate properly (and this results in the “stdin: is not a tty” notice below…).

This results in an email from Cron that looks somthing like this:

From: Cron Daemon
Date: Tue, Dec 23
Subject: Cron su –login –command ‘apt-get update -qq; apt-get upgrade -q -y; exit’
To: root

stdin: is not a tty
Reading package lists…
Building dependency tree…
Reading state information…
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

So, how often? Automated beats manually. A Weekly scheduled task is so much better than the ‘intention to log in routinely and update the box’. You have to balance the risks associated with the update itself interfering with the services the box provides against the risks of not having up-to-date patches .

One thing that is critical -> if you are using automated patch updates, you need to either get emails with the update output or log this data to a fixed location. In the event that one of these updates causes you a problem, you want to know exactly where to look to aid in your trouble-shooting.

Set-up Mail Transfer Agent (MTA)

System services will send email to root whenever something isn’t right. So, unless you are going to do some very agressive log monitoring, getting those messages forwarded to your actual email box will be invaluable. Not just from a security perspective, but also to understand the operational integrity (aka health) of the system.

Unfortunately, details of properly setting up a Mail Transfer Agent are beyond the scope of what I can explore in a blog posting. For our purposes, the goals are:

• Set-up an MTA that will work with your ISP/hosting provider
• Configure .forward file for the root account
• Make sure the MTA is NOT an “open relay”

I use Postfix in a pretty trivial configuration. If  you research the “install postfix” on Google, it will at first seem like you are embarking on a complex journey. Not so. Those posts are directed toward people who want to set up complete email solutions. The only goal from a security and operational awareness point of view is that email messages that get sent to root get forwarded to you, the system admin. To accomplish that, the steps should go something like:

• Install Postfix
• Select either “Internet Site” or “Smart Host”
• Continue through the configuration wizard

(and of course, the devil is in the details of that last step…)

Install Log Watch

# apt-get install logwatch

Now that you have the required facilities to have email sent from your host, install Logwatch. The default installation on Ubuntu will automatically send a daily email with tons of useful information, including:

• Summaries of the logs of utilities and services (postfix, httpd, etc.)
• PAM unix authentication attempts and failures
• SSH session activity
• Uses of the SUDO command
• Disk space levels

After a few days, you will be able to scan through the email in a few seconds and understand that your host is operating normally. And of course, if you detect any problems, having a few of these emails to look back through for changes is also very valuable.

Well, the fundamentals are never super exciting. But these steps will put you well on your way to securing and hardening your host. In part 2, properly configuring and hardening SSH will be discussed.

Cheers, Erik