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
 
I corsi di Ingegneria
 
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