Security Administration II Trusted Systems Social Context

Security Administration II

Trusted Systems

Social Context

CSCE 522 - Farkas 2

When Can a System be Trusted?

Identify objectivesIdentify risks and vulnerabilitiesIdentify security requirementsIdentify systems with appropriate

levels of trust

CSCE 522 - Farkas 3

VulnerabilitiesSecurity objectives:

Prevent attacksDetect attacksRecover from attacks

Attacks: against weaknesses in the information systems

Need: find weaknesses

CSCE 522 - Farkas 4

Avoiding Weaknesses Vulnerability monitoring Secure system development User training and awareness Avoiding single point of failure

CSCE 522 - Farkas 5

Vulnerability MonitoringIdentify potential weaknesses in

existing information systemsReveal wide-range of

vulnerabilities

CSCE 522 - Farkas 6

Secure Software Installation

Correct installation of softwareChange default settingsValidate upgrades/changesPatch new security flaws

CSCE 522 - Farkas 7

Vulnerability Detection Tools

COPSSATANSARASAINTMBSA SAFEsuiteMany others

CSCE 522 - Farkas 8

COPSComputer Oracle and Password

System FREEChecks vulnerabilities of UNIX

systems

CSCE 522 - Farkas 9

SARA

Security Auditor’s Research Assistant

Descendent of SATAN

CSCE 522 - Farkas 10

SAINT

Security Administrator’s Integrated Network Tool

Commercial product


MBSA

Microsoft Baseline Security Analyzer

Checks Microsoft systems


SAFEsuite Internet Security Systems, Inc. Family of network security assessment

tools Web security scanner Firewall scanner Intranet scanner System security scanner)

Keyed to the IP address of the customer


Security Publications Legal publications: how to remove

vulnerabilities CERT advisories SANS Security Digest

Hacker publications: “how to” exploit known vulnerabilities

Security mailing lists


Early Security Criteria

1960s: US Department of Defense (DoD) risk of unsecured information systems

1981: National Computer Security Center (NCSC) at the NSA DoD Trusted Computer System Evaluation

Criteria (TCSEC) == Orange Book


Orange Book Orange Book objectives

Guidance of what security features to build into new products

Provide measurement to evaluate security of systems

Basis for specifying security requirements

Security features and Assurances Trusted Computing Base (TCB) security

components of the system


Orange Book LevelsHighest Security

A1 Verified protection B3 Security Domains B2 Structured Protection B1 labeled Security Protections C2 Controlled Access Protection C1 Discretionary Security Protection D Minimal Protection

No Security


Security Policy

C1 C2 B1 B2 B3 A1

DAC + + nc nc + nc

Object Reuse 0 + nc nc nc nc

Labels 0 0 + + nc nc

Label integrity 0 0 + nc nc nc

Exploration of labeled info 0 0 + nc nc nc

Labeling human-readable output 0 0 + nc nc nc

MAC 0 0 + + nc nc

Subject sensitive labels 0 0 0 + nc nc

Device Labels 0 0 0 + nc nc

0 no requirements+ added requirementnc no change

MAC(from lecture notes of Jajodia http:www.ise.gmu.edu)


Accountability

C1 C2 B1 B2 B3 A1

Identification and Authentication + + + nc nc nc

Audit 0 + + + + nc

Trusted Path 0 0 0 + + nc


Assurance changes

(from lecture notes of Jajodia http:www.ise.gmu.edu)


AssuranceC1 C2 B1 B2 B3 A1

System Architecture + + + + + nc

System Integrity + nc nc nc nc nc

Security Testing + + + + + +

Design Specification and Verification 0 0 + + + +

Covert Channel Analysis 0 0 0 + + +

Trusted Facility Management 0 0 0 + + nc

Configuration Management 0 0 0 + nc +

Trusted Recovery 0 0 0 0 + nc

Trusted Distribution 0 0 0 0 0 +


No covert channel



Documentation

C1 C2 B1 B2 B3 A1

Security Features User’s Guide + nc nc nc nc nc

Trusted Facility Manual + + + + + nc

Test Documentation + nc nc + nc +

Design Documentation + nc + + + +




Covert Channel AnalysisB1: no requirementsB2: covert storage channelsB3: covert channels (timing and

storage channels)A1: formal methods (proof of covert

channel analysis)



Design Specifications

DTLSDescriptive top-level specification

FTLSFormal top-level specification

Specifications for TCB (trusted computing base)



C and B Requirements

C2: no requirement B1: informal or formal model of the security

policy B2: formal model of the security policy that is

proven consistent with its axioms, B3: convincing argument shall be given that

the DTLS is consistent with the model



A Requirements

A1: FTLS (formal top-level specification) of the TCB

Formal and informal techniques to show that FTLS is consistent with the model

Convincing argument the DTLS is consistent with the model



Orange Book Classes

C1, C2: simple enhancement of existing systems. Does not break applications.

B1: relatively simple enhancement of existing system. May break some of the applications.

B2: major enhancement of existing systems. Will break many applications.

B3: failed A1 A1: top-down design and implementation of a

new system from scratch.(from lecture notes of Jajodia http:www.ise.gmu.edu)


Orange Book Criticisms

Mixes various levels of abstraction in a single document

Does not address integrity of dataCombines functionality and

assurance in a single linear rating scale



Functionality vs. Assurance

func

tion

alit

y

assurance

C1

C2B1

B2B3 A1

• functionality is multidimensional

• assurance has a linear progression



NCSC Rainbow Series Orange: Trusted Computer System

Evaluation Criteria Yellow: Guidance for applying the

Orange Book Red: Trusted Network Interpretation Lavender: Trusted Database

Interpretation



Assurance MethodsTestingPenetration testingFormal verificationValidationOpen source


Testing Developer testing User testing Penetration testing (aka tiger team

analysis, ethical hacking Can show existence of problems Can not show that problems don’t exist


Other Approaches Formal verification

Based upon assertions and proofs Validation

Show that all required functionality is present (not just that what is there works)

Open source A form of peer review A lot of debate on this


European Criteria German Information Security Agency: German Green

Book (1988) British Department of Trade and Industry and Ministry of

Defense: several volumes of criteria Canada, Australia, France: works on evaluation criteria 1991: Information Technology Security Evaluation Criteria

(ITSEC) For European community Decoupled features from assurance Introduced new functionality requirement classes Accommodated commercial security requirements


United StatesJanuary 1996: Common Criteria

(CC)Joint work with Canada and

EuropeSeparates functionality from

assurance


CC Functionality Audit Communications User data protection Identification and authentication Privacy Protections of trusted functions Resource utilization Establishing user sessions Trusted path


CC AssuranceConfiguration managementDelivery and operationDevelopmentGuidance documentsLife cycle supportTestsVulnerability assessment


Common Criteria Evaluation Assurance Levels (EAL)

EAL1: functionally tested EAL2: structurally tested EAL3: methodologically tested and checked EAL4: methodologically designed, tested and

reviewed EAL5: semi-formally designed and tested EAL6: semi-formally verified and tested EAL7: formally verified design and tested


National Information Assurance Partnership (NIAP)

1997: National Institute of Standards and Technology (NIST), National Security Agency (NSA), and Industry

Aims to improve the efficiency of evaluation

Transfer methodologies and techniques to private sector laboratories


NIAP Functions

Develop tests Test methods and tools for evaluating and

improving security products Develop protections profiles and associated

tests Establish formal and international schema for

CC


Security Awareness and Training

Major weakness: user unawareness Organizational effort Educational effort Customer training Federal Trade Commission: program to

educate customers about web scams


Avoid Single Point of Failure

Critical information resources IdentificationBackupHiding

Separation of dutiesMulti-person requirementsLimit temptations


A Legal Perspective Protecting Programs and Data Information and the Law Rights of Employees and Employers Software Failures Computer Crime Privacy

Ethical Issues in Computer Security


Relationship to Security Relationship of topics discussed to

computer security is not always clear

Legal and ethical issues involving computers are often, not always, security issues

Example: Ownership of program code


Legal IssuesLaws provide a framework in which

security issues can/must be addressedConstraints

Things you can’t doRequirements

Things you must do


Privacy IssuesCombine legal requirements and

social expectationsPrivacy refers to protection/release

of personal informationConfidentiality refers to

protection/release of information in general


Ethical Issues Ethics involves generally accepted

standards of proper behavior Ethical principle – “an objectively

defined standard of right and wrong” Ethical system – “a set of ethical

principles” The United States is an ethically

pluralistic society


Law and EthicsIt is possible for an action to be

legal but not ethicalIt is possible for an action to be

ethical but not legalWhat these actions are depends

upon the ethical system used


Some Privacy Issues Identity theft Data mining Carnivore Passport Anonymity Computer voting E.U. Data Protection Act (personal data) Gramm-Leach-Bliley (financial information) HIPAA (health information)


Additional Privacy Issues

US Privacy ActUS Electronic Communications Privacy Act

US Patriot Act


Software Ownership

Protecting information about software Possible protection mechanisms:

Trade secretCopyright (DMCA)Patent


Who/What is Protected?

Code and dataPersonal data

Rights of employees/employersProgram usersSystem users


Criminal vs. Civil Law

Criminal law – actions against the state Statutes

Civil law – actions against individuals/other private entities

PrecedentsContract law – actions in violation of a

contract


How are Computer Crimes Different from Other Crimes?

Unfamiliarity of criminal justice system with computers and computer terminology

Need to deal with intangible and easily copied property


International Issues

Laws are different in different countries.Computer networks are international.Who has “jurisdiction” over a computer

crime?Can software/data be effectively

excluded? Privacy concerns Cryptography


Ethical Principles

Consequence-based: teleology Egoism Utilitarianism

Rule-based: deontology Rule-deontology Personal

Professional codes of ethics

Documents

Security Administration II Trusted Systems Social Context