30
Andrew Pollack, NCT

Security

Embed Size (px)

DESCRIPTION

Security

Citation preview

Page 1: Security

Andrew Pollack, NCT

Page 2: Security

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!

Page 3: Security

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

Page 4: Security

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

Page 5: Security

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

Page 6: Security

Are you the weakest link?

Page 7: Security

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?

Page 8: Security

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

Page 9: Security

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

Page 10: Security

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

Page 11: Security

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

Page 12: Security

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

Page 13: Security

Policies & Procedures Matter

Page 14: Security

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

Page 15: Security

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?

Page 16: Security

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

Page 17: Security

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

Page 18: Security

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

Page 19: Security

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

Page 20: Security

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

Page 21: Security

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

Page 22: Security

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

Page 23: Security

Also known as “There he goes again….”

Page 24: Security

The most simple form of attack

“I’ve forgotten my password”

Similar “Human Engineering” Attacks

Page 25: Security

Not Domino Specific

Very well secured network environment

Very good physical security

More than 75% success rate

Page 26: Security

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

Page 27: Security
Page 28: Security
Page 29: Security

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: [email protected] 2.1.0 [email protected]... Sender ok

RCPT TO: [email protected] 2.1.0 [email protected]... Recipient ok

Subject: whatever you want250 2.1.0 [email protected]... 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.

Page 30: Security

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