IST346:

IST346: Information

SecurityPolicy

Monitoring andLogging

Today’s Agenda Overview of Information Security SA Activities Surrounding Information Security Incident Management System Monitoring and Logging

An overview of Information Security

Security is the relationship among

Assets

VulnerabilitiesThreats

What you’re trying to secure

Your weaknesses

What you’re securing from

Assets The user’s identity – login account Network bandwidth – denial of service, bot-

nets Storage / Disk space - warez Data – the most important asset of them all Reputation – one incident can ruin a

reputation.

Vulnerabilities Bad default, or weak passwords passwords. Unused services with open ports. Un-patched software vulnerabilities. Transmitting data in clear text. Open networks (modems, wired, or wireless) Physical access to systems. The users themselves.

Threats Financial motives

Identity theftPhishingSpamExtortionBotnets

Political motivesDanish sites hacked after Mohammed cartoons.

Personal motivesJust for fun.Insider revenge.

Goals of Security:

Data Protecti

onData

Integrity

System Integrity

System Availabil

ity

Keep data safe

Keep data accurate

Keep systems

operational

Keep systems accurate

“To protect and to serve your systems and data.”

Defense TypesPerimeter Security

Firewall off network to prevent intrusions. What about wireless? What about mobile computing?

Defense in Depth Secure systems at all levels:

Network perimeter (firewall) Intrusion detection System hardening

DefensesVulnerability mitigation

Use secure authentication systems. Deploy software in secure configuration. Patch security flaws quickly.

Attack mitigation Firewalls to prevent network attacks. IDS to detect attacks. Virus/spyware scanners.

User Education and Awareness Prevent So cal engineering

Social Engineering The human element of security Users are the weakest link Preys on people’s inherent trust in others

Kevin Mitnick - Famous Hacker Author of “The Art of Deception” and “No Tech

Hacking” One of his many social engineering stories http://www.youtube.com/watch?v=8L76gTaReeg

SA Security Activities

Activity OS / Server Hardening1. Secure the physical system.2. Install only necessary software.3. Keep security patches up to date.4. Delete or disable unnecessary user accounts.5. Use secure passwords.6. Disable remote access except where

necessary.7. Setup least privilege access.8. Run publicly accessible services in a jail.9. Check logs regularly.10. Configure firewall on each host.11. Run security scanner to check security.12. Document security configuration.

Slide #14

Security Activity: Log Checking Review logs every morning. Better yet, have a program scan them.

Logwatch / swatch Send logs to a central server for

security: attacker can’t hide tracks by deletingease of use: you can read all logs in one place

Slide #15

Activity: Security ScanningScan host security

Run bastille on host (linux).Run scw on Windows

Scan network security (Linux tools –free)Scan for open ports with nmap.Scan for vulnerabilities with nessus.

Slide #16

Activity: Intrusion DetectionHost-based intrusion detection

Check if system files are modified.Check for config / process modifications.Tools: tripwire, osiris, samhain

Network-based intrusion detectionNIDS = Sniffer + traffic analysis + alert system.Check for suspicious activities: port scans, etc.Check for attack signatures: worms, etc.Tools: snort, air snort

Slide #17

Activity: Security AuditingInternal and External Audits

Internal: by a group within organization. External: by a group external to organization.

Audit areas Check compliance with security policy. Check physical security of building, data center. Check that machines have up to date patches. Scan networks to verify hosts + services. Penetration testing.

Security Policy / Incident Reporting

Security PoliciesUser Level Policies

Users must sign before receiving resources.1. Acceptable Use Policy2. Monitoring and Privacy Policy3. Remote Access Policy

Business Level Policies4. Network Connectivity Policy5. Log Retention Policy

Slide #20

What is an Incident?Any violation of security policy:

Unauthorized access of information Unauthorized access to machines Embezzlement Virus or worm attack Denial of service attacks Email spam or harassment

Slide #21

Incident Response Goals1. Determine if a security breach occurred.2. Contain intrusion to prevent further damage.3. Recover systems and data.4. Prevent future intrusions of same kind.5. Investigate and/or prosecute intrusion.6. Prevent public knowledge of incident.

Monitoring and Logging

Something we do to Services

Service Monitoring Service Logging Observing service

activity in real-time This is done by a

computer, not a human.

Important events are passed on to a human (notification).

Keeping a historical records of service activity

This data grows over time and can become quite large.

Only referred to when needed to troubleshoot a problem or trace down a security incident.

Why Bother?

Why do we Monitor? Why do we Log? To detect / identify

problems quickly. Ideally you want to

know about it before your users do.

To determine if resources are being constrained or over utilized.

Help get to the root cause of an issue or incident.

Help us predict problem and avoid them.

Provide historical data or trends for service usage.

Report on service activity.

If you’re not measuring it you aren’t managing it

How Monitoring and Logging Work

Server

Service

LogNetwork Activity

Service Activity

External Service Monitor

Internal Service Monitor

EventEvent

SA

Example: Simple Web Service Monitoring

Linux Host: web.syr.edu

ApacheHTTPD

access_logNetwork Activity

Service Activity

nmap web.syr.edu

ps –aux | grep “httpd”

Event: Service stopped

Event: Port unavailable

What to Monitor, what to Log? Monitor for a condition. Send alert when the condition is met. Log the condition whether it sends an alert or

not.

Examples: (Why would you monitor/log these?) CPU utilization stays at 100% for X minutes. Free disk space drops below 10%. Port does not respond for 1500 ms HTTP request take more than 5 sec to get

response.

Better Monitoring Normal

Normal: When a service fails you send an alert. Proactive Monitoring

Proactive: When a service show signs it is about to fail you send an alert. (100% cpu, Long responses, etc.)

Automated Responses Normal: When a service fails you send an alert. Automated: When the service fails, you attempt to

restart it. If the restart fails, you send an alert. PM and AR are difficult and time-consuming to

implement, but are time savers for difficult problems with no permanent fix.

A layered approach is always better.

Alerts! Types:

Email TXT message SMS Page Automated dialer over POTS

Pick the appropriate Alert for the appropriate Event and time.

In a layered approach, you might send an email, and if the problem persists send a TXT, etc…

Logging Log files get very large

since they record all activity. Log file rotation – service points to a different log file

after a specified interval. Lets you backup log files Keeps the size of the files manageable. Log files are text and they compress nicely.

How long do you keep logs? Depends on service, depends on your policy It’s not a decision the SA should make.

Like an insurance policy. Not very useful until the off chance that you need it... then you’re glad you have it!

Questions?