Post on 24-Dec-2015
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 Protectio
n
Data Integrity
System Integrity
System Availabilit
y
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 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 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 Detection
Host-based intrusion detectionCheck 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 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
LogNetwork Activity
Service Activity
External Service Monitor
Internal Service Monitor
EventEvent
SA
Example: Simple Web Service Monitoring
Linux Host: web.syr.edu
ApacheHTTPD
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:
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?