Security

• of clients
• of servers
• of networks

Security basics

• No such thing as "perfect security"
  • complexity of software, machines, and network.
  • basic insecurity of network design.
• Security is a result of effective policy.
  • on what's important.
  • on what's permissible.

Security Illusions

• If I use the right tools, I'm secure.
• If I use 'secure' software, I'm secure.
• If I'm careful about what I do, I'm secure.

Security is not about tools/software

• Not about what you install,
• but about making difficult tradeoffs between usability and security.

All security decisions are tradeoffs between:

• convenience/user tolerance
• value of protected items
• cost of violating security

Some guiding principles:

• "A system is only truely 'secure' if it left disconnected and encased in 15 feet of concrete."
• "A system is 'secure' if it costs more to break into it than the access is worth to the cracker."
• "An encryption method for data is 'secure' if the time it takes to break it renders the protected data worthless."

Parts of Security

• Policy: what's important to protect?
• Architecture: general plan for enforcing policy.
• Implementation: specifics of insuring security.

Policy

• What is our mission?
• What do we need to protect to accomplish that mission?
• What is the relative importance of each thing we protect?
• What services do we need to avoid compromising in order to accomplish that mission?
• What is the relative importance of each service we must provide?

Role of policy

• documents best practices.
• assures consistency of application.
• assures management backing for your actions.
• protects from various liabilities.

Without policy

• you don't know what you're protecting.
• you don't know what you can do.
• you may not even know what's wrong.

True story

• didn't have a Tufts Responsible Use Policy.
• students didn't know what was incorrect behavior.
• sometimes we didn't, either.
• result: ad-hoc enforcement, which means that anyone with a good lawyer escaped punishment.
• (real case: we denied access to suns to a known hacker and had to endure 2 hours of being yelled at by his lawyer.)

Real policies

• wider range that security
• Source: Barbara Dijker, "A Guide to Developing Computing Policy Documents", SAGE Short Topics in System Administration, 1996.

Scope of a real policy

• usage: what can users expect?
• security: how will we preserve data integrity?
• safety: how will we preserve physical integrity (no sodas in the lab!)?
• facilities and resources: breakdown of rights and privileges to utilize each computing resource.
• responsible use agreements: documents that users sign to assure that they will abide by appropriate policies.

What are we protecting?

• Integrity of data.
• Privacy of data.
• Reliability of service.
• Authenticity of users and transactions.
• against Liability in being used as an intermediary.

Policy realities

• As an administrator, your power only extends as far as outside forces allow:
  • management tolerance.
  • legal liabilities and limits.
  • strategic mission objectives.
  • ethical limits of your profession.
• You need the power of law to back you up when you make policy decisions.
• You must prove that your administrative policy doesn't conflict with any of the above.
• Truly effective policies are not made by mere mortals, but by committees containing you, management, and lawyers.

Legal limits upon system administrators

• Privacy laws
  • Family Educational Rights and Privacy Act (FERPA) (for student records).
  • various Medical record privacy acts (for patients).
• Computer Crime laws
  • anti-hacking (breakins and denial of service)
  • anti-fraud (authenticity issues)
• Patent and Trademark infringement.
  • public key encryption is patented in the US (but not abroad) Using it outside patent agreement is illegal in the US (but not in Europe)
• International Trade in Arms Regulations (ITAR).
  • public key encryption is technically a munition. Exporting without a license is illegal.
• "Due dilligence"
  • if someone breaks into your system, are you liable for what the other person does, or negligent because you didn't prevent it?

Ethical limits upon system administrators

• Ethics: a system of beliefs about proper and correct behavior that is more stringent that the law.
• Really a social contract between you and your users.
• double-edged: what you can do and what they can do.

Parts of System Administrator Ethics

• Insuring trust
• Preserving privacy
• Preserving system integrity and availability.
• "Do no harm"

What to do when policies go wrong

• Case example: your policy asks you to do something illegal (e.g., pirate software).
• Ethical dilemma: you've been asked to do something unethical (against the SAGE code of ethics)
• Legal dilemma: it's also illegal.
• SAGE advice (SAGE Ethics Committee, Hal Pomerantz)
  • Explain situation to management.
  • If they insist, get it in writing.
  • In other words, make the organization liable for its actions!

Example: sketch of EECS policies

• Users are given access for pursuit of coursework and research.
• Home directories of users are private unless there is evidence of wrongdoing.
• Wrongdoing includes:
  • academic dishonesty
  • cracking other systems.
  • unauthorized access to other users' accounts.
  • harassment.
• Wrongdoing can lead to loss of privileges and academic or disciplinary action.
• We strive to maintain a network on which you can do coursework.
• Other privileges (such as publishing access, games, etc) are provided as convenient, but may disappear without notice.

The double edge:

• Policy tells what we will do but also what we won't.
• This is not just a network, but a community.
• Policy defines what it is to be a citizen, what you can expect from being one, and what we expect from you.

General security principles

• avoid exposure
• deny unnecessary services
• monitor allowed services

Security activities

• Risk assessment: actions that determine how likely incidents are.
• Prevention: actions that keep incidents from happening.
• Mitigation: actions that cope with incidents as they happen.
• Detection: actions to monitor and detect problems (without implied action).
• Recovery: actions that can recover (when appropriate) from detected states.

Prevention

• keeping software up to date.
• Obeying Computer Emergency Response Team (CERT) advisories (www.cert.org)
• limiting user actions.

Mitigation

• Filtering/control
  • of events/requests
  • of network traffic
  • of service requests

Detection

• Monitoring
  • system configurations.
  • log file contents.
  • network traffic.

Recovery

• Keeping recoverable copies of
  • data and transactions.
  • system programs.
  • user files.

Detection includes State Monitoring

• watch system configuration for problems.
• detect ASAP.
• alert appropriate humans.

Detection includes Event Monitoring

• watch incoming requests for service
• detect possible attacks.
• alert appropriate humans.

Mitigation means some form of filtering

• classify events
• allow some, deny others.
• record if and when people attempt illegal acts.

Examples of security tools in action:

• prevention: OPIE
• prevention: sudo
• detection: tripwire
• mitigation: SWatch
• mitigation: tcp wrappers