Valentina Casola » 14.Security Evaluation; TCSEC and ITSEC

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…).
• …

“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.

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;
• 3^rd 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.

Output