Vai alla Home Page About me Courseware Federica Living Library Federica Federica Podstudio Virtual Campus 3D Le Miniguide all'orientamento Gli eBook di Federica La Corte in Rete
 
 
Il Corso Le lezioni del Corso La Cattedra
 
Materiali di approfondimento Risorse Web Il Podcast di questa lezione

Valentina Casola » 14.Security Evaluation; TCSEC and ITSEC


Traditional Security Efforts

So we apply:

  • Network Perimeter Security:
    • Simple/Common: “Border Firewall”.
    • Advanced: Internal Segmentation, IPS.
  • Access Control on Systems/Applications:
    • Simple/Common: username/password, app/sys permissions.
    • Advanced: Strong authentication, RBAC and IDM.
  • System Auditing (for the very advanced).
  • Disaster Recovery.

But still we face critical security issues.


What traditional security efforts cannot counter

  • Exposed output files from the systems.
  • Information Leakage by authorised users.
  • Changes by authorised users.
  • Outsourcers:
    • Collection Agencies.
    • Call Centers.
    • Printing Houses.
    • IT Outsourcers (Service Providers, Development…).
  • Administrators.
  • Mobile Users.
  • Lost laptops, Removable media (USBs…).

Redefining Business System

  • In essence we had omitted:
    • the Points of Use of the Information/Data processed by the system, i.e. the various workstations/laptops;
    • the People;
    • the Processes.

“Why traditional controls fail”

Privileged Users

  • Privileged usershave and should have access to the systems and data, so Access Control at Apps/servers cannot help a lot.
  • On the other hand we have no “Access Control” at the Point of Use, i.e. the user’s PC/Laptop, Terminal Services.

Vanishing Perimeters

  • With so many parties accessing systems and data inside the border firewall we cannot talk about network perimeters anymore.

Infrastructure-centric Controls are not enough

  • Our Data live beyond Infrastructure controls (e.g. laptops, outsourcers, business partners…).
  • With current Infrastructure-centric controls is very difficult to obtain a view of our data “whereabouts”, who accessed what and what they did with it!

Evaluating Systems and Goals

  • Goals:
    • Why evaluate?
  • Evaluation criteria:
    • TCSEC (Orange Book).
    • Common Criteria.
  • Standard ISO17799.
  • Show that a system meets specific security requirements under specific conditions:
    • Called a trusted system.
    • Based on specific assurance evidence.
  • Formal evaluation methodology:
    • Technique used to provide measurements of trust based on specific security requirements and evidence of assurance.

Evaluation Methodology

  • Provides set of requirements defining security functionality for system.
  • Provides set of assurance requirements delineating steps for establishing that system meets its functional requirements.
  • Provides methodology for determining that system meets functional requirements based on analysis of assurance evidence.
  • Provides measure of result indicating how trustworthy a system is with respect to security functional requirements:
    • Called level of trust.

Why Evaluate?

  • Provides an independent assessment, and measure of assurance, by experts:
    • Includes assessment of requirements to see if they are consistent, complete, technically sound, sufficient to counter threats.
    • Includes assessment of administrative, user, installation, other documentation that provides information on proper configuration, administration, use of system.
  • Independence critical:
    • Experts bring fresh perspectives, eyes to assessment.

Bit of History

  • Government, military drove early evaluation processes:
    • Their desire to use commercial products led to businesses developing methodologies for evaluating security, trustworthiness of systems.
  • Methodologies provide combination of:
    • Functional requirements.
    • Assurance requirements.
    • Levels of trust.

Evaluation Classes A, B, C and D

A1 Verified protection; significant use of formal methods; trusted distribution; code, FTLS correspondence.

B3 Security domains; full reference validation mechanism; increases trusted path requirements, constrains code development; more DTLS requirements; documentation.

B2 Structured protection; formal security policy model; MAC for all objects, labeling; trusted path; least privilege; covert channel analysis, configuration management.

B1 Labeled security protection; informal security policy model; MAC for some objects; labeling; more stringent security testing.

C2 Controlled access protection; object reuse, auditing, more stringent security testing.

C1 Discretionary protection; minimal functional, assurance requirements; I&A controls; DAC.

D Did not meet requirements of any other class.

Common Criteria: 1998–Present

  • Began in 1998 with signing of Common Criteria Recognition Agreement with 5 signers:
    • US, UK, Canada, France, Germany.
  • As of May 2002, 10 more signers:
    • Australia, Finland, Greece, Israel, Italy, Netherlands, New Zealand, Norway, Spain, Sweden; India, Japan, Russia, South Korea developing appropriate schemes.
  • Standard 15408 of International Standards Organization.
  • De facto US security evaluation standard.

Evaluation Methodology

  • CC documents:
    • Overview of methodology, functional requirements, assurance requirements.
  • CC Evaluation Methodology (CEM):
    • Detailed guidelines for evaluation at each EAL; currently only EAL1–EAL4 defined.
  • Evaluation Scheme or National Scheme:
    • Country-specific infrastructures implementing CEM.
    • In US, it’s CC Evaluation and Validation Scheme; NIST accredits commercial labs to do evaluations.

CC Terms

  • Target of Evaluation (TOE): system or product being evaluated.
  • TOE Security Policy (TSP): set of rules regulating how assets managed, protected, distributed within TOE.
  • TOE Security Functions (TSF): set consisting of all hardware, software, firmware of TOE that must be relied on for correct enforcement of TSP.

Protection Profiles

  • CC Protection Profile (PP): implementation-independent set of security requirements for category of products or systems meeting specific consumer needs:
    • Includes functional requirements:
      • Chosen from CC functional requirements by PP author.
    • Includes assurance requirements:
      • Chosen from CC assurance requirements; may be EAL plus others.
    • PPs for firewalls, desktop systems, etc.
    • Evolved from ideas in earlier criteria.

Security Target

  • CC Security Target (ST): set of security requirements and specifications to be used as basis for evaluation of identified product or system:
    • Can be derived from a PP, or directly from CC:
      • If from PP, ST can reference PP directly.
    • Addresses issues for specific product or system:
      • PP addresses issues for a family of potential products or systems.

CC Requirements

  • Both functional and assurance requirements.
  • EALs built from assurance requirements.
  • Requirements divided into classes based on common purpose.
  • Classes broken into smaller groups (families).
  • Families composed of components, or sets of definitions of detailed requirements, dependent requirements and definition of hierarchy of requirements.

ISO 17799

  • “A comprehensive set of controls comprising best practices in information security”.
  • Basically… an internationally recognised generic information security standard.

Purpose

  • “It is intended to serve as a single reference point for identifying a range of controls needed for most situations where information systems are used in industry and commerce”.
  • Facilitation of information flow in a trusted environment.

ISO 17799-1 identifies:

  • 10 control objectives essential as a basis for an Information Security Management System.
  • 127 controls.

Structure of ISO 17799

ISO 17799-1: A Code of Best Practice.
BS  7799-2: Assessment Process for	Certification.

ISO 17799-1: A Code of Best Practice. BS 7799-2: Assessment Process for Certification.


Structure of ISO 17799 (cont’d)

  • ISO 17799 based on assuring integrity, availability, and confidentiality of information assets.
  • Assurance is attained through controls that management creates and maintains within the organisation.
  • Ten key controls identified by BS 7799 for the implementation of a successful information security program are:
    • A documented information security policy.
    • Allocation of information security responsibilities within the organization.
    • Information security education and training.
    • Security incident reporting and response.
    • Virus detection and prevention controls.
    • Business continuity planning.
    • Control of proprietary software copying.
    • Critical record management processes.
    • Protection of personal data (privacy).
    • Periodic compliance reviews.

Ten Key Controls


1. Security Policy

Objective

  • To provide management direction and support for information security.

Policy should cover

  • definition of information security;
  • statement of management intent;
  • allocation of responsibilities;
  • scope;
  • an explanation of specific applicable principles, standards and compliance requirements;
  • an explanation of the process for reporting of suspected security incidents;
  • a defined review process for maintaining the policy;
  • means for assessing the effectiveness of the policy, embracing cost and technological changes;
  • nomination of the policy owner;

2. Security Organisation

Objective

  • To manage information security within the organisation.
  • To maintain the security of organisational information processing facilities and information assets accessed by third parties.
  • To maintain the security of information when the responsibility for information processing has been outsourced to another organisation.

Subjects covered

  • setting up of a management forum (committee);
  • roles of the forum;
  • allocation of security responsibilities;
  • establishment of an authorisation process for new hardware and software purchases;
  • 3rd party access to organisational data;
  • steps needed to prevent and detect unauthorised access via 3rd party access;
  • security requirements in outsourcing contracts;

3. Asset Classification & Controls

Objective

  • To maintain appropriate protection of corporate assets and to ensure that information assets receive an appropriate level of protection.

Subjects covered

  • establishing an asset register for hardware, software and information;
  • advice on classifying and labelling assets:
    • NB: Classifying and labelling assets is a pre-requisite for a Threat/Risk Assessment.

4. Personnel Security

Objective

  • To reduce risks of human error, theft, fraud or misuse of facilities.
  • To ensure that users are aware of information security threats and concerns and are equipped to support the corporate security policy in the course of their normal work;
  • To minimise the damage from security incidents and malfunctions and learn from such incidents.
  • Subjects covered:
  • risks to data and systems by deliberate & accidental human action:
    • user error;
    • fraud;
    • theft;
  • making security responsibilities part of a formal job description;
  • screening potential staff;
  • training of staff in basic security awareness;
  • establishing security incident handling framework.

5. Physical Policy

Objective

  • To prevent unauthorised access, damage and interference to business premises and information.
  • To prevent loss, damage or compromise of assets and interruption to business activities.
  • To prevent compromise or theft of information and information processing facilities.

Subjects covered

  • need to establish secure areas with physical entry controls;
  • need to physically protect hardware equipment to prevent theft;
  • need to protect network cabling from tampering;
  • security of equipment taken off site or sent for disposal.

6. Communications & Operations Mgmt

Objective

  • To ensure the correct and secure operation of information processing facilities.
  • To minimise the risk of systems failures.
  • To protect the integrity of software and information.
  • To maintain the integrity and availability of information processing and communication.
  • To ensure the safeguarding of information in networks and the protection of the supporting infrastructure.
  • To prevent damage to assets and interruptions to business activities.
  • To prevent loss, modification or misuse of information exchanged between organisations.

6. Communications (follows)

  • Large section that deals with security for computer systems.
  • Explains main areas of risk, but stops short of explaining technical measures necessary.

Subjects covered:

  • Viruses.
  • Malicious software.
  • Change control.
  • Backup.
  • The keeping of accurate access logs.
  • Security of system documentation.
  • Disposal of media.
  • Protection and authentication of data during transfers and in transit.
  • Security of Email.

7. Access Controls

Objective

  • To control access to information.
  • To prevent unauthorised access to information systems.
  • To ensure the protection of networked services.
  • To prevent unauthorised computer access.
  • To detect unauthorised activities.
  • To ensure information security when using mobile computing and tele-networking facilities.

Subjects covered

  • access control and how it can be applied to different types of system:
    • issue and usage of passwords;
    • duress alarms;
    • automatic terminal time outs;
    • physical access to terminals;
    • software metering/monitoring.

8. System Development & Maintenance

Objective

  • To ensure security is built into operational systems.
  • To prevent loss, modification or misuse of user data in application systems.
  • To protect confidentiality, authenticity and integrity of info.
  • To ensure IT projects & support activities are conducted in a secure manner.
  • To maintain security of application system software & data.

Subjects covered

  • acquisition of new systems modification to existing ones:
    • input data validation;
    • data encryption;
    • security of data files;
    • protection of test data;
  • procedures for software development and maintenance:
    • configuration management;
    • change control;
    • protection of data.

9. Business Continuity Planning

Objective

  • To counteract interruptions to business activities and to critical business processes from the effects of major failures or disasters.

Subjects covered

  • an overview of the case for a comprehensive business continuity plan which should be designed, implemented, tested and maintained.

10. Compliance

Objective

  • To avoid breaches of any criminal or civil law, statutory, regulatory or contractual obligations and of any security requirements.
  • To ensure compliance of systems with organisational security policies and standards.
  • To maximise the effectiveness of and to minimise interference to/from the system audit process.

Subjects covered

  • areas where an organisation needs to ensure that it complies with its legal and contractual obligations:
    • Contractual commitments (e.g.: software licenses);
    • intellectual property rights.

Steps to Implementation


Steps to Implementation (follows)

BS 7799 Accreditation.

BS 7799 Accreditation.


Output


  • Contenuti protetti da Creative Commons
  • Feed RSS
  • Condividi su FriendFeed
  • Condividi su Facebook
  • Segnala su Twitter
  • Condividi su LinkedIn
Progetto "Campus Virtuale" dell'Università degli Studi di Napoli Federico II, realizzato con il cofinanziamento dell'Unione europea. Asse V - Società dell'informazione - Obiettivo Operativo 5.1 e-Government ed e-Inclusion