95 Security Policy 2006'12'01

1
?????????????? 95???????????????
?????(Security Policy) 2006.12.01

• ? ? ? ? ? ? ? ???? ?
• ? ? ?

2
Outline

• The Basics
• Building Security Using a Solid Infrastructure
• Ask the Right Questions
• Document the Companys Security Policies
• Basics for the Technical Staff
• Management and Organizational Issues

• Appendix
• Make Security Pervasive
• Stay Up-to-Date Contracts and Technologies
• Produce Metrics
• Organization Profiles
• Small Company
• Medium Size Company
• Large Size Company
• E-commerce Site
• University

3
Reference

• Thomas A. Limincelli, Christine Hogan, The
  Practice of System and Network Administration,
  Addison Wesley

4
Background (1/3)

• In this talk, we describe the basic building
  blocks that an organization needs for a
  successful security program, some guiding
  principles, and some common security concerns.
• There is much more to security than firewall,
  intrusion detection, and authentication schemes.
• Although all of these are key components of a
  security program, security administrators also
  have to take on many different roles and the
  skills for those roles are quite diverse.
• Security is a large and complex area that
  requires even more communication skills than over
  areas of system administration and must be a
  cooperative effort that crosses administrative
  divisions.

5
Background (2/3)

• There are some areas that the technical staff
  should concentrate on and others with which
  management can help.
• The technical staff must
• consider business needs, convenience for their
  customers,
• staying up-to-date with attacks and
  vulnerabilities,
• building a solid authentication and authorization
  system,
• and selecting good security software.
• Ideally, the technical staff must also
• do their best to keep up-to-date with what is
  happening in the security world by building good
  contacts within the industry and keeping an eye
  on new technologies.

6
Background (3/3)

• The security groups management can help with
• resources and staffing,
• establishing an incident response team,
• engaging external auditors,
• and selling security to other groups within the
  organization.
• Ideally, security should be a pervasive part of
  the organization culture.
• This takes a lot of time and effort to build and
  will only really succeed if it comes from senior
  management.
• One of the best ways to gain management support
  is to produce meaningful metrics on the work that
  the security team is doing.

7
The Basic (1/2)

• The design of security system should be based on
  simplicity and minimalism.
• An overly complex system will prove to be
  inflexible, difficult to use and maintain, and
  will ultimately be weakened or circumvented for
  people to be able to work effectively.
• Some consider security and convenience to be
  inversely proportional.
• That is, to make something more secure makes it
  more difficult to use.
• The reality is that this can be true, but when
  security is done correctly, it takes into account
  the customers ease of use.

8
The Basic (2/2)

• Security is a huge, changing filed, and to keep
  current, SAs working in security must focus on
  all their attention on the security arena.
• Senior SAs with the right mind-set for security
  are good candidates for being trained by
  specialists to join the security team.
• A successful security architecture has security
  built into the system, not just bolted on at the
  end.
• Good security involves an in-depth approach with
  security hooks at all levels of the systems.
• It should be built on solid foundations in
  policies that are approved and supported by
  senior management.
• Building security systems relies on the other
  systems infrastructure.

9
Building Security Using a Solid Infrastructure

• It is important to build the basic system and
  network infrastructure and to get it right
  because other things, such as security, depend on
  it.
• Building an effective security program requires a
  solid computer and network infrastructure that is
  built with security in mind.
• Deploying security effectively requires
• that you have known, standard configurations
• that you can build and rebuild secured systems
  quickly and cheaply,
• that you can deploy new software and patches
  quickly
• that you can track patches levels and versions
  well

10
Ask the Right Questions (1/4)

• Before implementing a successful security
  program, you must find out
• What you are trying to protect
• Server hosts/network, data/information
• From whom it must be protected
• roles
• What the risks are
• server hosts/network down, compromised, etc.
• Database corrupted, information theft, etc.
• What it is worth to the company
• information theft , etc.

11
Network Security
Data Security Assurance
Confidentiality Integrity
Authentication

• Benefit
• Ensures data privacy
• Shuns
• Sniffing
• Replay

• Benefit
• Ensures data is unaltered during
• transit
• Shuns
• Alteration
• Replay

• Benefit
• Ensures identity of originator or
• recipient of data
• Shuns
• Impersonation
• Replay

12
Information Protection Examples-- Legends

• Alice, valuable resource, address A
• Bob, good guy, address B
• Charlie the cracker address C (often masquerading
  Bob)

13
Network Vulnerabilities
14
Ask the Right Questions (2/4)

• There are business decisions that should be made
  through informed discussion with the executive
  management of the organization.
• Document the decisions that are made during the
  process and review the final document with
  management.
• The document will need to evolve with the company
  but should not change too dramatically or
  frequently.

15
Ask the Right Questions (3/4)

• Information Protection
• Information protection includes protect against
  malicious alternation, deliberate and
  accidentally release of information, and theft or
  destruction
• Level of security
• Public
• Company confidential
• Strictly confidential

16
Ask the Right Questions (4/4)

• Service Availability
• If a company relies on the availability of
  certain electronic resources to conduct its
  business, part of the mission of the security
  team will be to prevent malicious denial of
  service attacks to those resource.
• Theft of Resources
• Sometimes, the company will want to protect
  against theft of resources.
• Computer cycle, Bandwidth privates, etc.
• Decide What Is Important, Then Protect It

17
Document the Companys Security Policies (1/2)

• Different places need different sets of policies
• and, to some degree, that set of policies will
  continually evolve and be added to as new
  situation arises.
• Lack of Policy Hampers (??) the Security Team
• The following common policies are a good place to
  start in building your repertoire of policies.
• Acceptable Use Policy (AUP)
• Monitoring and Privacy Policy
• Remote Access Policy
• Network Connectivity Policy
• Log Retention (??) Policy
• Exit Policy

18
Document the Companys Security Policies (2/2)

• Policies are the foundation of everything that a
  security team does, and formal policies must be
  created in cooperation with people from many
  different departments.
• The human resources department
• Acceptable Use Policy, Monitoring and Privacy
  Policy
• Creating and implementing the remedies for any
  policy breach
• The legal department
• Whether to track and prosecute (??, ??) intruders
• How and when to involve law enforcement when
  break-ins occur

19
Acceptable Use Policy (AUP)

• An acceptable use policy describes
• who the legitimate users of the computer and
  network resources are
• and what they are permitted to use those
  resources for.
• An AUP may also includes some examples of
  unacceptable use.
• The legitimate users of the computer and network
  resources are required to sign a copy of this
  policy,
• Acknowledge (??) that they have read and agreed
  to it before being given access to those
  resources.
• Multiple AUPs may be in place when a company has
  multiple security zones (??????, ????).
• ????, ????, ????, IT ??, ?????

20
Monitoring and Privacy Policy

• The monitoring and privacy policy describes the
  organizations monitoring of their computer and
  network resources, including activities on
• individual computers, network traffic, e-mail,
  web browsing, audit trails, and log monitoring.
• Monitoring may be considered as an invasion of
  privacy
• thus this policy should explicitly state what, if
  any, expectations of privacy an individual has
  while using these resources.
• The individual should read and sign a copy of
  this policy before getting access to the
  resources.

21
Remote Access Policy

• The remote access policy should
• explain the risks associated with unauthorized
  people gaining access to the network,
• describe proper precautions for the individuals
  secrete information,
• and provide a way to report lost or stolen remote
  access tokens so that they could be disabled
  quickly.
• Everyone should complete and sign a copy of this
  policy before being granted remote access.
• It should also ask for some personal information
  (for example, shoe size and favorite color) ,
  through which people can be identified over the
  telephone.

22
Network Connectivity Policy

• The network connectivity policy describes
• how the company sets up network connections to
  another entity or some shared resources for
  access by a third party.
• The policy should be
• distributed to all levels of management
• and stipulated (??, ??) that the security team be
  involved as early as possible.
• The policy should list
• different forms of connectivity and shared
  resources that are supported,
• which offices can support third-party
  connections,
• and what types of connections they can support.

23
Log Retention Policy

• Log Retention Policy describes what is logged and
  for how long.
• Logs are useful for tracking security incidents
  after the event but taking up large amount of
  space if retained indefinitely.
• It is also important to know whether logs for a
  certain date still exist if subpoenaed (?????
  ??) for a criminal case.
• It may also address log reduction.

24
Exit policy (1/2) (for someone who leaves a
company)

• The exit policy typically involves notifying the
  human resources department,
• which also notifies other departments, such as
  pay rolls, facilities, information technology.
• The most useful tool in the exist process is a
  checklist for the manager of the person who is
  leaving.
• It reminds the manager to ask for
• Keys, access badge(s), identity badge(s),
  authentication token(s), home equipment, company
  phone cards, company credit card, mobile phone,
  pager, radio and any other equipment that the
  person might have.

25
Exit policy (2/2)

• It should also reminds the manager to contact the
  IT department at the appropriate time.
• The IT department must have an efficient process
  (i.e., automated as much as possible) for
  disabling a persons access.
• Effectively disabling access is particularly
  important for adverse terminations.

26
Get High-Level Management Support (1/3)

• For a security program to succeed, it must have
  high-level management support.
• The management of the company must be involved in
  setting the policies and ground rules for the
  security program,
• so that the right decisions are made for the
  business
• and so they understand what decisions were made
  and why.
• If you are to represent the security group,
• you will need to able to clearly explain the
  possibilities, risks and benefits, and to do so
  in business languages, not technical jargon.

27
Get High-Level Management Support (2/3)

• In some cases, the security staff may disagree
  with the managements decisions.
• If you find that you disagree with those
  decisions, try to understand why they were made.
• Business decisions take into account both
  technical and non-technical needs.
• Once the corporate direction on security has been
  agreed upon, it must be documented and approved
  by the management team.
• It must then be made available and publicized
  within the company.

28
Get High-Level Management Support (3/3)

• Ideally, there should be a security officer at a
  high level of management hierarchy who is not a
  part of the IT division.
• The person should have both business skills and
  experience in the area of information protection.
• The security officer should head up a
  cross-functional information protection team with
  representatives from
• the legal, human resources, IT, engineering,
  sales and support divisions, or whatever the
  appropriate divisions may be in the company.
• The security officer will be responsible for
  ensuring
• that appropriate policies are developed,
  approved, and enforced in a timely manner,
• and that the security and information protection
  team are taking the appropriate actions for the
  company.

29
Centralize Authority

• At all levels, there must be a central authority
  for decisions that relate to security.
• Business decisions, policymaking, architecture,
  implementation, incident response, and auditing.
• If the company feels that certain autonomous
  business units should have control over their own
  policymaking, and so on, then each unit should
  have its own central authority.
• The computer and network resources of each unit
  should be clearly divided from the rest of the
  company, and the interconnections should be
  treated as connections to a third-party with each
  side applying its own policies and architectural
  standards to those connections.

30
Basics for the Technical Staff

• Meet the Business Needs
• Stay Up-to-Date Attacks
• Vulnerability Scanning
• Authentication (??) and authorization (??)
• Not everyone is security-aware
• Shared voicemail
• Shared role accounts make Identification
  difficult
• Select the right products and vendors
• Internal auditing

31
Meet the Business Needs

• When designing a security system, you must always
  find out what the businesss needs are and meet
  those needs.
• Remember that there is no point in securing a
  company to the point that it cannot conduct its
  business.
• If the people using your security system cannot
  work effectively, they will find a way to defeat
  it or a way around it.

32
Meet the Business Needs (cont.)

• To effectively meet the business needs, you have
  to understand
• what people are trying to do
• how they are trying to do
• and what their workflow looks like
• You will also have to
• find out what all the reasonable technological
  solutions are
• and understand in great detail how they work
  before you can pick the right solution.

33
Meet the Business Needs (cont.)

• The right solution
• Enable people to work effectively
• Provides a reasonable level of security
• Is as simple and clean as possible
• Can be implemented within a reasonable time scale
• Remember, if you make it easy to do the right
  thing, people will do it.
• People want to do what is right, but they will do
  what is easy.

34
Stay Up-to-Date Attacks

• A security professional must keep up-to-date with
  the current types of attacks and the ways to
  protect the companys systems from those attacks.
• This means tracking several mailing lists and web
  sites. E.g., Bugtraq, CIAC, CERT/CC, AUSCERT,
  etc.
• A security professional should try to find out
  about new vulnerabilities as soon as possible to
  evaluate
• how best to protect the companys systems
• and how to check for attacks that take advantage
  of this vulnerability.

35
Authentication and authorization

• One of the fundamental building blocks of a
  security system is a strong authentication system
  with a unique identity for each person and no
  accounts used by multiple people.
• Along with the authentication system goes the
  authorization system that specifies the level of
  access that each person is authorized to have.
• Authentication gives the persons identity
• And authorization determines what the person can
  do.

36
Authentication and authorization (cont.)

• A role account is one that gives people
  privileges to perform one or more functions they
  cannot perform with their normal account
  privileges.
• The SA role, the database administrator role, web
  administrator role, etc.
• Shared accounts, even shared role accounts,
  should be avoided.
• Shared accounts make it difficult, if not
  impossible, to have accountability.
• If something goes wrong, there may be no way to
  tell who did what.
• It also makes it a lot harder to disable someone
  access completely when he leaves the company.

37
Authentication and authorization (cont.)

• A strong authentication system gives you a high
  degree of confidence that the person the computer
  believes it has authenticated is actually that
  person and not someone else using that persons
  credentials.
• For example, a biometric mechanism, or a
  token-based system (i.e., a physical device
  secret that he remembers)
• If he gives his physical device to someone else,
• It the device was stolen,
• It can be useful to tie the strong authentication
  mechanism to something that has real value to the
  individual.
• For example, credit card, phone card, money,
  house key, driver license, or is biometric

38
Authentication and authorization (cont.)

• At times, something will go wrong with the strong
  authentication mechanism,
• and you will need a way to authentication people
  over the phone, particularly if they are
  traveling.
• You have to prepare for this eventually when you
  initially set up people in the strong
  authentication system.
• Have them fill out a form, providing questions
  and answers that can be used to authenticate them
  over the phone. (e.g., their shoe size, their
  favorite color, etc.)
• If a person can successfully authenticated
  himself over the phone line in this way, then we
  could grant him temporary access until the
  original problem could be fixed.

39
Select the right products and vendors

• Simplicity
• Security
• Open source
• Open source debate (intrusion, security)
• Closed source suspicions of security through
  obscurity
• Usability
• Functionality
• Vendor issues
• Integration
• Cost of ownership
• Futures

40
Simplicity

• Simple systems are more reliable and more secure
  than complex ones.
• Several small, simple components that interact
  are likely to have fewer security problems than a
  single large complex system.
• The more complex a system, the harder it is to
  test in details, and the more likely it is to
  have unforeseen problems that can be exploited by
  an attacker.

41
Security

• Why do you believe that the product is of
  reasonably secure ?
• Research the product and find out who the
  principal designers and programmers are.
• Are they well respected in this industry? What
  else have they done ?
• How well have their previous products worked and
  how secure are those products ?
• How does the product address some known problem
  areas ? (e.g., mail delivery, FTP, etc.)
• Look through a couple of years of security
  advisories and pick up a recurring problem area
  to investigate.

42
Usability

• How do different components interact ?
• How long does a configuration change in one area
  affect other areas?
• For example, a firewall with both packet
  filtering and proxies
• How long does it take to train new people on the
  product ?
• Is it easy to understand and verify the
  configuration ?
• How easy is it to configure the application in a
  way that is not secure?

43
Vendor issues

• Maintenance patches and updates are very
  important for a security-sensitive product.
• To be able to report problems to a vendor and
  have a reasonable expectation of getting a quick
  fix or workaround for the problem ?
• How security-conscious is the vendor ?
• Do they release security patches for their
  products ?
• What is their mechanism for notifying customers
  of security problems ?

44
Integration

• How well will the product integrate with the rest
  of your network infrastructure ?
• Will it use your existing authentication system ?
• What kind of load does it put on your network
  (and on other key systems) ?
• If it has to talk to other systems or people
  through a firewall, are the protocols (it use)
  adequately supported by the firewall ?
• Open protocols vs. proprietary protocols
• Can its logs be sent to a central log host ?
• What network services does it expect, and do you
  provide them already ?
• Does it run on an OS already supported and
  understood at the site ?

45
Cost of ownership

• How long does it take to configure the software ?
• Are there any autoload options that can help
  standardize the configuration and speed the setup
  time ?
• How much day-to-day maintenance is there on the
  system ?
• Does it need lots of tuning ?
• Are people in your organization already familiar
  with it ?
• Or are you going to train them ?
• How hard will it take a new person comfortable
  with your configuration ?

46
Futures

• How well does the product scale ?
• What are the scaling options when it reaches
  capacity ?
• What direction is the vendor taking the product
• Does it match your organizations direction ?
• E.g., Unix-based vs. Windows-based
• Is the product likely to die soon or stop being
  developed ? (e.g., Benq-Simens)
• How long are versions supported ?
• How often do new releases come out ? (e.g.,
  Ms-Vista)
• What is the market acceptance of this product ?
• Is it likely to survive market pressures ?

47
Internal Auditing

• What do we mean when we say auditing ?
• Checking whether security environments are in
  compliance with policies and design criteria
• Checking employee and contractors lists against
  authentication and authorization databases
• Physical checking on machine rooms, wiring and
  telecom closes for foreign devices

48
Internal Auditing (cont.)

• What do we mean when we say auditing ?
• Checking that relevant machines are up-to-date
  with security patches
• Scanning relevant networks to verify what
  services are offered
• Launching sophisticated, in-depth attacks against
  particular areas of the infrastructure, with
  clear specified success criteria and limitations

49
Internal Auditing

• Logging and Log Processing
• Internal Verification
• Per-project Verification
• Physical Checks

50
Logging and Log Processing

• Logs are an important source of security
  information.
• Logs can help trace what has happened in an
  attack.
• Logs can be analyzed to help detect attacks and
  gauge the seriousness of an attack.
• Logs should be processed by a computer to extract
  useful information and archived for a predefined
  period to be available for re-examination if an
  event is discovered.
• Logging and Log Processing
• a security standpoint vs. a practical standpoint

51
Logging and Log Processing (cont.)

• All security-sensitive logs should go to one
  central place so that
• they can be processed together
• and the information from different machines could
  be correlated.
• Security-sensitive logs should not remain on
  security-sensitive machines,
• because the logs could be erased or modified by
  an attacker that compromises those machines.
• The central logs must be very well secured to
  protect the integrity of the logs.

52
Internal Verification

• Consider ways that you can check for anomalies on
  your network and important systems. For example,
• Strange routes on network
• Routes go in strange directions
• Traffic on unexpected source
• Check what machines and services are visible on
  public networks to make sure that nothing new or
  unexpected has appeared.
• Intrusion Detection System (IDS) should make some
  type of anomalies detection easier, as well as
  other kinds of attacks detection.

53
Per-project Verification

• Periodically check on each security project to
  make sure that the configuration has not been
  materially changed.
• Make sure that is still matches the design
  specification and conforms to all appropriate
  policies.
• Check with people using the security system to
  see whether it serves their needs adequately and
  whether they anticipate any new requirements
  arising.

54
Physical Checks

• Check on areas that are key points in the
  computing, networking, or communications
  infrastructure.
• Data centers, networking closets,
  telecommunication closets, video-conferencing
  rooms, wiring between such rooms, wiring between
  buildings.
• Case Study Physical Security Breach
• telephone switch Hooked with a monitoring devices

55
Management and Organizational Issues

• There are several issues that the security team
  needs management support.
• Maintaining reasonable staffing level for the
  size of the organization, with the appropriate
  roles within the group ( ????????).
• Helping with coordination with the rest of the
  system administration managers to establish an
  incident response team (????????)
• Setting up a relationship with an outside
  auditing company and scheduling their work to fix
  in with the needs of the rest of the organization
  ( ??)
• ????????, ????????, ?????????????

56
Resources

• The security team needs access to various
  resources.
• One key to success is to have lots of contacts in
  the industry.
• They then get to know what others are doing and
  what others consider to be state of the art.
• It enables them to benchmark how the company is
  doing comparing with other companies.
• Are they spending too much on security or too
  little ?
• Are they lacking some important policies ?
• They can also find out experiences others have
  had in trying to implement some new technology
  and what the return on the investment has been.
• Has anyone had any particular positive or
  negative experiences with a new product that the
  security company is considering ?

57
Resources (cont.)

• Contacts are made through attending conferences
  regularly and becoming a part of some select
  Internet security focus groups.
• The security team needs people with a variety of
  skills.
• Policy writers
• Security Architects
• Implementers
• Operations staff
• Auditors
• Incident response team members

58
Security architect

• The security architect (, should be on
  cross-functional teams) represents the security
  group to the rest of company.
• The one responsible for staying in touch with
  what is happening within the company and finding
  out for which projects the groups need to prepare
• The one who finds out what the requirements and
  business needs for each project are and
  identifies the key people.
• The one design the security environment and takes
  an overview of what is happening with security
  within the company
• The one involved with vendor relations, tracking
  technologies, products, and futures.
• The one who decide when (or whether) the company
  should move toward a new technology

59
Incident Response

• Response policy
• Prosecution policy
• Disconnection policy
• Communication policy

60
External Audit

• Briefly, it is recommended to split the auditing
  function with
• the internal auditing team tracking things with
  the ongoing basis
• and the external group being brought in
  periodically for large-scale audits and for the
  benefits associated with their external
  viewpoint.
• The role of the external auditing team is
  examining the security of the company from the
  outside,
• which would cover in-depth attacks against
  particular areas and scanning if exposed networks
  and remote access points.
• External auditing should include penetration
  auditing
• Penetration test must be coordinated

61
External Audit (cont.)

• Using external auditors has several benefits.
• It give the security team independent feedback on
  how they are doing and provides extra pairs of
  eyes examining the companys securities.
• The consults should have the advantage of
  distance from the work that is going on,
• Their approach will be unaffected by expectations
  and inside knowledge.

62
External Audit (cont.)

• Ideally, the auditing group should not be
  involved in the design or maintenance of the
  companys security systems.
• Senior management will usually value getting an
  outside view of the companys security,
• and if the security consults are experienced in
  this area, they may well have more data to
  present to senior management on the existing
  state of the art in the industry,
• the resources that other similar companies assign
  to security
• and the risks associated with any shortcoming
  they have found or have been told about by the
  security team,
• The external group may be able to help the
  internal security team to get more resources.
• They may also have good ideas on approaches to
  take or advices on software and/or hardware to
  use.

63
Cross-Functional Teams

• Legal
• System Administrators
• Product Development
• Field Offices

64
Appendix The Icing ( ????)

• Making Security Pervasive
• Stay Up-to-date Contacts and Technology
• Produce Metrics

65
Making Security Pervasive

• A good information protection program will make
  everyone awareness of security and IP issues.
• If you can make security a part of the way that
  people work and think, the job of the security
  team will be become much easier.
• Case Study
• IBM Clean Desk Policy, Offices and Conference
  rooms without windows (i.e., against telescope
  spying)
• Motorola the Protection of Proprietary
  Information (POPI)

66
Stay Up-to-Date Contacts and Technology (1/3)

• Contacts within the security industry can be a
  good source of information on
• current attacks and vulnerabilities,
• varying product experiences,
• and emerging technologies.
• Going to security conferences is a good way to
  build these contacts.
• Security professionals are typically paranoid
  about disclosing their experiences to people that
  they do not known very well, so it is important
  to attend lots of conferences, get involved and
  recognized, and build a good rapport with others
  at the conferences.

67
Stay Up-to-Date Contacts and Technology (2/3)

• You should also aim to keep up with
• all the new technologies being developed,
• their supposed benefits,
• how they work, and
• their deployment and operational needs.
• In doing this, you will need to develop a skill
  for distinguishing snake oil (?????) from a
  useful product.

68
Stay Up-to-Date Contacts and Technology (3/3)

• For any new product idea,
• there typically are several fundamentally
  different approaches taken by the vendors,
• and it is often difficulty to tell how
  successfully any of them will be.
• However,
• watching the development of the different
  approaches,
• understanding the operational implications,
• and knowing the people behind various products
• help us predict which products and
  technologies might succeed.

69
Produce Metrics (????, 1/3)

• Metrics for security are very difficult.
• If you can produce some forms of metrics that
  make sense, describing at some level
• how the security team is performing
• and what value they are giving the company for
  the money,
• then it will be easier to convince management
  to fund security infrastructure projects.

70
Produce Metrics (2/3)

• Having an external auditing team may be a useful
  source of metrics.
• The area that was audited or attacked,
• The level of success,
• The possible cost of a breach in security of that
  area
• If you have a security perimeter, you may be able
  to gather data
• on the number of attacks or possible attacks seen
  outside and inside the security perimeter,
• thus enabling you to graph the level of
  protection provided by your security perimeter.

71
Produce Metrics (3/3)

• Example Metrics
• Simple graphs of the numbers of machines visible
  to people outside the company
• Statistics on the number of services available
• Number of vulnerabilities
• Number of security patches (that the team) needed
  to make overall by OS and by applications
• Good metrics should help management and other
  non-security people (within the company)
  understand at some level
• what you are doing and how well you are doing.
• Good metrics help build confidence in the
  security team for the rest of the company.

72
Organization Profiles

• Depending on the size and function of the
  organization
• Small Company (i.e., between 20 and 100)
• One ore two SAs, security will be a fairly small
  component of one SAs job.
• Should have an acceptable use policy and a
  monitoring and privacy policy
• Medium-Size Company (i.e., between 1000 and 3000)
• Large Company (i.e., more than 20000)
• E-commerce Site
• University

73
Organization profiles university environment

• The university environment is typically very
  different from that of a business.
• In a business, the people who have access to
  network are typically quite trusted by
  definition.
• In a university, however, the people who have
  access to the network are typically not trusted
  by default, in part because physical access is
  quite open.
• A university typically have administrative
  networks and computers that have restricted
  access and tight security controls.
• It also has academic networks that are quite
  open.
• Frequently, it will have open access to and from
  the Internet because it is a research environment
  where openness and learning are considered to go
  hand-in-hand.

74
Organization profiles university environment

• A university must have an acceptable usage policy
  and a monitoring and privacy policy that every
  computer user signs before getting access to the
  computing systems.
• University usually have less money to spend on
  their computing environment in general and
  security in particular.
• In a university, you will need to have in-depth
  security on key servers and additional security
  around the administrative networks.
• For the open access machines in the labs, you
  need to have a good auto-install and auto-patch
  system to find balance among security, research,
  and teaching needs.