Security

Andrew Pollack, NCT

English is the only language I speak◦ -- Unless you count programming languages

I will try to speak clearly, but if I am moving too quickly, or too slowly, please make some kind of sign, so I can adjust!

We will all point at you

Set all noise making toys to “Stun” please

If you need to type on a laptop or a Blackberry – move toward the back please

Administrator & Developer since version 2.0

Products◦ NCT Search, NCT Compliance Search, and NCT Simple Sign On, and now

Second Signal

Services◦ Site Performance Reviews◦ Application Development◦ Administrative Overhaul◦ Security Review & Penetration Testing

IBM Lotus Beacon Award Winner Firefighter

◦ Lieutenant of Cumberland, Maine – Engine 1

In firefighting, just like Server Administration it's all in the planning

Security From A Big Picture Approach

Big New Locks on Rusty Old Chains

What do I look for in a Security Review

Story Time

Summary

Are you the weakest link?

How good are your backups? A denial of service vector

Have you switched to IP Telephony? Your telephones may now be programmable computers

Who can access your server room?

Can your LAN administrators access the file systems on your Domino servers?

From a Security Officer Perspective “There are only two levels of paranoia – absolute,

and insufficient.”

From an End User Perspective “These are my friends and coworkers, I trust them

completely”

There is no perfect balance. You must learn to assess the risk and apply security in layers

Categorize Applications, then apply standard security practices based on the category

This protects developers and administrators

Some schemas I’ve seen Green, Yellow, Red Open, Internal, Confidential, Executive

Considerations for categorizing risk Employee contact data Customer list information Banking, tax, or medical information Company Planning information Company financial information

Most security problems come from inside, not outside hackers

Most administrative failures are infrastructure related, but have security implications

Sometimes, you need a way to fix it now and explain it later – reporting is critical

Internal Employee Mistakes Taking customer data to work out of the office Password Sharing Unattended Workstations

Abuse of Administrative Authority Reading people’s mail files Sending communication on behalf of someone else Intercepting Logs, Complaints, or Bad News Altering ‘metrics’ in help desk and other applications

Insufficient Termination Procedures Former Administrators or Employees Retaining Access

Unauthorized Copying of Data Employees taking the customer list as they resign

In Firefighting, we say “Try before you pry!”

You’re only as secure as your certifiers

Quit worrying about visible hash values unless everything else is locked down first

When in doubt, log and report

Policies & Procedures Matter

In a REVIEW

◦ I ask you questions and believe your answers◦ Typically 2 Days Talking + a Document◦ Cooperative Effort with the Administrative Team◦ Cannot be certified

In an AUDIT◦ I assume you my be wrong◦ Trust, but verify◦ Tends to be somewhat adversarial◦ Very Expensive, but certified accurate

From the Root Certifier on Down If you’re not using the CA, every admin you’ve ever

had probably has a copy

If your certifiers are ‘potentially compromised’ almost everything else we lock down is potential still vulnerable

User Certificates (ID Files) Who can assign them? What is the process for recovery (lost password or ID) Do you REALLY still keep copies of them somewhere?

Do you track every database?

“Owner” of the application Responsible developer? Expected size & activity ACL Requirements Scheduled Agent Requirements Security Level Category

Update tracking information every “N” months

People tend to accumulate group membership

This makes them ideal targets

Do you track every group?

“Owner” of the group Security Level Category

Update tracking information every “N” months

Group owner should “sign-off” on the accuracy periodically

Avoid Designer & Manager Access in ANY database on Production servers

VERY easy to crash servers

VERY easy to destroy data

VERY easy to exploit users

ECL’s are the single most important protection you have against intentional exploitation

Use “Design Signature” ID files and allow ONLY those to perform higher risk activities

Do not give “Design Signature” ID files to developers. An ADMIN must sign a changed application to move it to production

Never Allow End Users to Design or Manage their own databases

Local Databases must be encrypted

Local hard disks should be encrypted

Use password management policies

I love being told

◦ “HTTP Isn’t Running on our Servers”◦ “SMTP Isn’t Running on our Servers”◦ “LDAP Isn’t Running on our Servers”

Translated, this means “We’re not bothering to manage the HTTP password”

I can usually find one of these running on at least one of their servers

Set up exactly as a new temporary employee Repeat testing a new full time employee

Bring a copy of Designer on USB drive Never assume Designer is unavailable

ECL is the first thing I check If mine is set too open, most employees will be as well

CATALOG.NSF makes a great shopping list Shows me important databases Shows me databases with groups in common

Browsing Groups tells me who’s got what access

Also known as “There he goes again….”

The most simple form of attack

“I’ve forgotten my password”

Similar “Human Engineering” Attacks

Not Domino Specific

Very well secured network environment

Very good physical security

More than 75% success rate

Send a message to someone with a link

The link is actually a hotspot

The hotspot actually opens the page indicated

The hotspot also does other things

User Impersonation Attack

Very Difficult To Spot

220 mail.domain.ext ESMTP Sendmail (version); (date)

HELO local.domain.name250 mail.domain.ext Hello local.domain.name [loc.al.i.p], pleased to meet you

MAIL FROM: mail@domain.ext250 2.1.0 mail@domain.ext... Sender ok

RCPT TO: mail@otherdomain.ext250 2.1.0 mail@otherdomain.ext... Recipient ok

Subject: whatever you want250 2.1.0 mail@domain.ext... Subject okThis is the message body....250 2.0.0 ???????? Message accepted for deliveryQuit221 2.0.0 mail.domain.ext closing connectionConnection closed by foreign host.

Stop using big new locks on rusty old chains

Get control over your certifiers

Get control over your developers

Get control over your users & their local data storage devices

Get control over the databases & groups you’ve got deployed on your servers