95 Security Policy 2006'12'01 - PowerPoint PPT Presentation

1 / 74
About This Presentation
Title:

95 Security Policy 2006'12'01

Description:

In this talk, we describe the basic building blocks that an organization needs ... policies are a good place to start in building your repertoire of policies. ... – PowerPoint PPT presentation

Number of Views:19
Avg rating:3.0/5.0
Slides: 75
Provided by: liuta
Category:
Tags: policy | security

less

Transcript and Presenter's Notes

Title: 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.
Write a Comment
User Comments (0)
About PowerShow.com