IST346:  Information Security Policy  Monitoring and Logging

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 theft Phishing Spam Extortion Botnets  Political motives Danish sites hacked after Mohammed cartoons.  Personal motives Just for fun. Insider revenge.

Goals of Security: Data Protection Data Integrity System Integrity System Availability Keep data safe Keep data accurate Keep systems operational Keep systems accurate “To protect and to serve your systems and data.”

Defense Types Perimeter 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

Defenses Vulnerability 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 Socal 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 

SA Security Activities

Activity OS / Server Hardening 1. 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 deleting ease of use: you can read all logs in one place

Slide #15 Activity: Security Scanning Scan 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 Detection Host-based intrusion detection Check if system files are modified. Check for config / process modifications. Tools: tripwire, osiris, samhain Network-based intrusion detection NIDS = 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 Auditing Internal 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 Policies User Level Policies Users must sign before receiving resources. 1. Acceptable Use Policy 2. Monitoring and Privacy Policy 3. Remote Access Policy Business Level Policies 1. Network Connectivity Policy 2. 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  spam or harassment

Slide #21 Incident Response Goals 1. 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 Log Network Activity Service Activity External Service Monitor Internal Service Monitor Event SA

Example: Simple Web Service Monitoring Linux Host: web.syr.edu Apache HTTPD access_log Network 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:   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 , 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?