techponder

The last post concluded with the cry “there has to be a better way!”.

So far we have established:

• Security Guides are a good idea and exist in almost all organizations.
• Security audits are good and widely used.
• Security guides are often poorly written, subject to interpretation, and difficult to apply.
• Security audits are expensive and not performed as often as they should be.

Hmmm…. Well, computers are good at following rules and measuring things. And if security guide rules are precise enough to be implemented and measured, they are very close to what you need to create a computer program.

The obvious next step is to create computer programs to implement security rules and perform computer audits!

In fact, this is what has been done for years. Numerous programs have been written for security, many security capabilities are built into operating systems, and scripts to configure systems are widely used.

However: security at the enterprise level is a big, complex undertaking.

You need a large investment in tracking threats as they emerge. It would be terribly convenient if there were a standard way to talk about threats – for example, the first 6 people who identify a new computer virus are going to call it different things, unless something is done to create a standard definition.

The vast majority of computer security issues are quickly fixed after they are identified. Decades of experience show that most computer intrusions can be prevented by applying existing patches. The question is what patches need to be applied to each specific system? This is a more complex question than it appears to be – few organizations automatically apply all patches to all systems. Instead, they test patches and carefully apply specific patches to specific systems.

The challenge is knowing which patches have been applied, which patches are available, and which patches are needed for each system. What is the risk addressed by each patch, what is the impact, and how relevant is the exposure?

Creating a useful set of security rules is a huge undertaking. If each organization is 90% common with other organizations and 10% unique, it is incredibly wasteful for each organization to build 100% of the security rules themselves.

And enterprise systems are complex. You need a workflow and extensible frameworks to be able to effectively secure, manage and monitor them.

All of these things call out for an industry wide initiative to build a standard foundation for automating security.

Next: Security Checklists and the US National Checklist Program

The last post laid out guidelines for a security guide.

We’re now at the point where we can discuss a system audit. We have defined what an audit is, what security requirements are, and what a security guide is.

At the most basic level, a system audit involves examining a system to verify that it conforms to specifications. This includes operational specifications for the role the system is performing, verifying the integrity and configuration of the system, and compliance against the company security guide.

In many cases system audits are manual processes. A team of people, either internally or from an external company hired to do the audit, go though a written set of checklists and manually verify system settings and configuration.

These audits are time consuming, tedious, and expensive. They are also error prone…

As a result, companies may only audit a system every six months, once a year, or even every two years.

There has to be a better way!

Next: Automation – a Security Imperative

The previous post explored the kinds of information that might be in a security guide.

Let’s lay out some basic requirements for a security guide:

• The security guide must exist. It must be available, updated, and maintained.
• The security guide must incorporate relevant government and industry requirements.
• The security guide must be actionable. If it can’t be implemented it is useless.
• The security guide should be pro-active, describing what should be done, not what is forbidden. And, where applicable, how to do it.
• It should be possible to verify compliance with the security requirements through a system audit.
• The security guide should support the company mission.

This last item may strike you as a bit odd… Recall that the reason we have computer systems is to generate business value. The security guide should balance security risk against generation of business value. If a computer system can’t be used to generate business value, you might as well get rid of it. And, of course, the most secure system is one that doesn’t exist! (Just for the record, this is a joke…)

Ideally, the security guide is a tool to improve the operation of an organization, balancing protection needs against business needs, ease of use, and the threat profile a company actually faces.

Next: System Audits – There Has to be a Better Way!

The last article introduced the concept of a security guide – but what is it?

In many cases a security guide is a binder full of often vague, occasionally overly specific and sometimes conflicting requirements. It has usually grown and evolved over a number of years and is written by and for people. Thus, many of the requirements must be interpreted.

Consider a requirement that might be in a security guide: passwords must be secure.

Helpful, isn’t it? What does this really mean? Passwords must be resistant to brute force attacks? Passwords must be difficult to guess? Passwords can’t be shared? Passwords can’t be written down? You can’t have the same password for different accounts and systems?

All of these are good. Under certain circumstances. But what does this actually mean?

In some cases it simply means that people will be charged with violating company security policy if their password is ever mis-used! A recent Dilbert cartoon captured this nicely: “we trained them to lie by punishing honesty” (paraphrased).

Helpful. Really helpful…

Much better is telling people what to do. The SANS Password Construction Guidelines is a good start, as well as the complementary Password Protection Policy. It tells you how to construct a strong password:

Strong passwords have the following characteristics:

• Contain at least 12 alphanumeric characters.
• Contain both upper and lower case letters.
• Contain at least one number (for example, 0-9).
• Contain at least one special character (for example,!$%^&*()_+|~-=\`{}[]:”;'<>?,/).

Poor, or weak, passwords have the following characteristics:

• Contain less than eight characters.
• Can be found in a dictionary, including foreign language, or exist in a language slang, dialect, or jargon.
• Contain personal information such as birthdates, addresses, phone numbers, or names of family members, pets, friends, and fantasy characters.
• Contain work-related information such as building names, system commands, sites, companies, hardware, or software.
• Contain number patterns such as aaabbb, qwerty, zyxwvuts, or 123321.
• Contain common words spelled backward, or preceded or followed by a number (for example, terces, secret1 or 1secret).
• Are some version of “Welcome123” “Password123” “Changeme123”

This is much better! The key point is that we have gone from a completely abstract passwords must be secure to a set of discrete measurable rules. If it can’t be measured, it is nothing but opinion…

Note that these specific requirements may not meet your needs – for example, you may determine that 12 character passwords and not required, and that 8 characters is sufficient. You may discover that some of your software doesn’t allow special characters. Or you may have realized that passwords simply do not provide adequate security and have implemented a more robust authentication method like multi-factor authentication.

But we’re getting ahead of ourselves. We will lay out some basic requirements for a security guide in the next post.

Next: High Level Requirements for a Security Guide

The previous article introduced security audits, which are actually audits of security specifications.

There are many potential sources for security specifications. Some of them are government standards. For example, in the United States, HIPAA, the Health Insurance Portability and Accountability Act of 1996, specifies requirements for administrative safeguards, physical safeguards, and technical safeguards of medical records and personally identifiable information. Anyone dealing with Protected Health Information must comply with HIPAA.

The credit card industry has the Payment Card Industry Data Security Standard or PCI DSS, which must be followed by anyone who is handling credit card information.

The SANS Institute offers a wide range of security training and resources, including a set of Information Security Policy Templates that provide examples of best practices that can be customized for your organization. For example, the Server Security Policy specifies things like “all internal servers deployed at <company name> must be owned by an operational group that is responsible for system administration” – in other words, no zombie servers that no-one is responsible for!

The United States Department of Defense has prepared Security Technical Implementation Guides which specify how government computers will be configured and managed.

Of course there are numerous books on computer security, many including guidelines and checklists.

Finally, each organization must prepare their own security guide which lays out the security rules that they choose to follow. This is critical because each organization has their own set of requirements, needs, and threats. You can’t simply say “all computer systems must be completely secure” – first, this is impossible. There is a famous observation that the only truly secure computer system is one that is melted into slag, ground into dust, cast into a block of concrete, and dumped into the deepest part of the ocean. Second, implementing the highest levels of security for all systems is expensive and makes the systems very difficult to use.

As we have discussed before, computer security in the real world is a risk management exercise. Risk can’t be eliminated, it can’t be ignored, and it should be managed intelligently.

An organizations security guide should be based on applicable government and industry requirements, accepted best practices, and the specific requirements of the organization.

Next: What is a Security Guide?

In conversations with large companies and small companies, literature review and looking at best practices for security, one of the most common tools that essentially everyone uses is a security audit. In most cases the security audit is performed regularly – it isn’t just a one time event. OK, this sounds good, but what is it?

Dictionary.com definitions of audit include “an official examination and verification of accounts and records”, “the inspection or examination of a building or other facility to evaluate or improve its appropriateness, safety, efficiency or the like” as well as “to examine and verify an account by references to vouchers”.

A computer security audit means verifying that the system complies with specifications for computer security.

So far we haven’t really said anything – we’ve just laid the foundation for the three big questions:

• What are these magical specifications for computer security? And where do they come from?
• How is compliance against the security specifications measured?
• How is the computer security audit performed?

Missing from this list is the huge question of what is done about lack of compliance against the security specifications. Is fixing any security issues identified in the audit considered part of the audit, or is it a separate exercise?

Next: Security Specifications

The password managers we discussed in the last post are a good start. If you only use one system a local password database is all you need.

Most people have multiple “devices” – a PC, a laptop, a smartphone, a tablet, and the number keeps growing. It would be terribly convenient to have access to your passwords on all of your devices, and to have everything automatically updated when you add or change a password.

This is where network – or today CLOUD BASED (highlighted for dramatic emphasis…) – password managers come into play. These networked password managers share, distribute, backup, and replicate your passwords.

Putting your passwords IN THE CLOUD should make you nervous. It is important to do your homework before choosing one – don’t just choose the first one that comes up on a search!

There are several places to look. Wikipedia has a List of Password Managers. Information Week has an article on 10 Top Password Managers. Network World published Best tools for protecting passwords. Mac World produced Mac password managers. At a minimum make sure that the password managers you are considering have at least some public review and feedback. You should also do web searches looking for user experience and any issues with the various password managers.

For cloud based password managers, one of the most important things is to make sure that you retain control of the passwords. This is done by encrypting the password data locally, on your system, and only sending encrypted data to the cloud. Done properly, the master encryption password for the password database never leaves your system – no one, including the company hosting your password manager, can decrypt your password. Of course this also means that if you lose your password manager password you are out of luck; no one can recover it.

As an anecdote, not a recommendation, a thoroughly paranoid colleague who works in the security space and whose opinions I respect recommends LastPass.  I prefer open source password managers that can be audited, like KeePassX, but there don’t seem to be any with good Cloud integration.

Next: Computer Security Audits