Security Certifications and

Building a Secure System…in search of the

Holy Grail?

Security Certifications and

Building a Secure System…in search of the

Holy Grail?

Lesson 21

Building Secure SystemsBuilding Secure Systems

Vulnerabilities frequently found in operating systems and application programs.

Problem is not new, we’ve always had problems with the security of our systems and flaws in the operating system.

Is it really that hard to build a secure system?

Why systems are not secureWhy systems are not secure

Security is fundamentally difficult.What is adequate for most functions isn’t for security“good enough” doesn’t apply for security

Security is often (usually) an afterthought. Security is viewed as an impediment. False solutions impede progress

industry subject to ‘fads’ -- quick fixes cause us to become complacent.

Technology is oversold -- the problem is often with the people not the computers.

Errors are made – and not found (inadequate testing, poor programming techniques).

Example of poor programming/errorsExample of poor programming/errors Buffer Overflows

result of poor programming practice– use of functions such as gets and strcpy

these don’t check input for boundaries

may allow individual to gain root or admin access

Sample Buffer Overflow ExampleSample Buffer Overflow Example#include <stdio.h>#include <string.h>

void func(char *p){ char stack_temp[20]; strcpy(stack_temp, p); printf(stack_temp);}

int main(int argc, char* argv[]){ func(“I AM MORE THAN TWENTY CHARACTERS LONG!”); return 0;}

Buffer OverflowsBuffer Overflows

Program

Execute A

Return

Subroutine A

Read Variable

Data

Process Stack

Return Addr

Buffer Overflows

Program

Execute A

Return

Subroutine A

Read Variable

Data

Process Stack

Return AddrNew Addr

Another Routine

Exploits

Buffer Overflowsfingerd, statd, talkd, …result of poor programming practice

Shell Escapesspecial character in input string causes escape to shell

Cover your tracksCover your tracks

Adjust log filesRootKit– contains sniffer, login program that disables logging,

“hacker” versions of several system utilities (e.g. ps)

Loopinglaunch attack from another system you’ve compromised thus hiding trailgreatly increases complexity of tracking

Security KernelSecurity Kernel The HW and SW that implements the “reference monitor”

All accesses that subjects make to objects are authorized on information in an access control database.The specific checks that are made and all modifications to the access control database are controlled by the reference monitor in accordance with the established security policy.

Audit File

ReferenceMonitor

AccessControl

Database

ObjectsSubjects

Three Principles for Security KernelsThree Principles for Security Kernels

Completeness: it must be impossible to bypass.All access to information must be mediated by the reference monitor.

Isolation: it must be tamperproofThe OS and the reference monitor should “protect” themselves from modification.

Verifiability: it must be shown to be properly implemented.Good software engineering practices.Simplicity of function in the kernel.Minimize the size of the kernel.

The “Orange Book”The “Orange Book” The NCSC (NSA) developed the Trusted Computer

System Evaluation Criteria (TCSEC) Designed to meet three objectives

to provide guidance to manufacturers as to what security features to build into their productsto provide the DoD customers with a metric to evaluate the degree of trust they could place in a computer systemto provide a basis for specifying security requirements in acquisition specifications

The Orange BookThe Orange Book

Particular emphasis is on preventing unauthorized disclosure of information.

Based on Bell-La Padula security modelSimple Security Condition

– allows a subject read access to an object only if the security level of the subject dominates the security level of the object.

*-Property– allows a subject write access to an object only if the security level of the

subject is dominated by the security level of the object. Also known as the Confinement Property.

“No Read Up/No Write Down”

The Orange BookThe Orange Book “Trusted Computing Base” Concept 7 Levels

D: Minimal ProtectionC1: Discretionary Security ProtectionC2: Controlled Access ProtectionB1: Labeled Security ProtectionB2: Structured ProtectionB3: Security DomainsA1: Verified Protection

The Orange BookThe Orange Book

Fundamental RequirementsFundamental Requirements

PolicySecurity PolicyMarking

AccountabilityIdentification: Individual subjects must be identified.Accountability: Audit information must be selectively kept and protected.

AssuranceAssurance: system must contain HW/SW mechanisms that can be independently evaluated to ensure system enforces requirements. Continuous Protection: mechanisms that enforce protection must be protected against tampering and unauthorized changes.

Documentation

Division C Class C1Division C Class C1

Division C Class C1Division C Class C1

Division C Class C2Division C Class C2

Division B Class B1Division B Class B1

TCSEC SummaryTCSEC Summary

The “Yellow Book”The “Yellow Book”

Open: Application developers do not have sufficient clearance or authorization to proved an acceptable presumption that they have not introduced malicious logic.Closed: Application developers (including maintainers) do have the clearance/authorization.

The “Yellow Book”The “Yellow Book”

The “Red Book”The “Red Book”

Trusted Network Interpretation (TNI) Two parts

Interprets Orange book for networks– interpretation– rationale

Describes additional security services that arise with networks.

Division C Class C1Division C Class C1

The Network Security ServicesThe Network Security Services

Issues with Any CertificationIssues with Any Certification Certifications take time

thus they generally have a hefty price associated with them.By the time the product is evaluated, its obsolete.

Who gets to do the evaluation?Lots of folks don’t want the government poking around their product, but can you trust some other company?

Certifications are for a single release, if you release a new version it will need to be evaluated too.

The ITSEC and Common CriteriaThe ITSEC and Common Criteria After the TCSEC was published, several European

countries issued their own criteria.The Information Technology Security Evaluation Criteria (ITSEC). Had a number of improvements.

– Permitted new feature definitions and functionalities.– Accommodated commercial evaluation facilities

Soon the U.S. was preparing to update the TCSEC. Instead of multiple standards, how about a joint one?

Thus, the birth of the Common Criteria

Common CriteriaCommon Criteria

Common CriteriaCommon Criteria

Common CriteriaCommon Criteria Has 7 Evaluation Assurance Levels (EAL)

EAL1: functionally testedEAL2: Structurally testedEAL3: Methodologically tested and checkedEAL4: Methodologically designed, tested, & reviewedEAL5: Semiformally designed and testedEAL6: Semiformally verified design and testedEAL7: Formally verified design and tested

Any collection of components can be combined with an EAL to form a Protection Profile.

Defines an implementation-independent set of security requirements and objectives.

Example Level DescriptionExample Level Description EAL1 - functionally tested

EAL1 is applicable where some confidence in correct operation is required, but the threats to security are not viewed as serious. It will be of value where independent assurance is required to support contention that due care has been exercised with respect to the protection of personal or similar information.This level provides an evaluation of the Target of Evaluation (TOE) as made available to the consumer, including independent testing against a specification, and an examination of the guidance documentation provided.

Level DescriptionLevel Description EAL2 - structurally tested

EAL2 requires the cooperation of the developer in terms of the delivery of design information and test results, but should not demand more effort on the part of the developer than is consistent with good commercial practice. As such it should not require a substantially increased investment of cost or time.EAL2 is applicable in those circumstances where developers or users require a low to moderate level of independently assured security in the absence of ready availability of the complete development record. Such a situation may arise when securing legacy systems, or where access to the developer may be limited.

Level DescriptionLevel Description EAL3 - methodically tested and checked

EAL3 permits a conscientious developer to gain maximum assurance from positive security engineering at the design stage without substantial alteration of existing sound development practices. It is applicable in those circumstances where developers or users require a moderate level of independently assured security, and require a thorough investigation of the TOE and its development without incurring substantial reengineering costs.An EAL3 evaluation provides an analysis supported by "grey box" testing, selective confirmation of the developer test results, and evidence of a developer search for obvious vulnerabilities. Development environmental controls and TOE configuration management are also required.

ICSA CertificationICSA Certification ICSA Labs initiated a program for certifying IT products

against a set of industry accepted, de facto standards.Standards are developed with input from security experts, vendors, developers, and users.Targets threats that actually occur frequently, not postulated ones (think covert channels).Goal is criteria appropriate for 80% of customers.

Has mechanism for certification of future versions.

ICSAICSA

ICSAICSA

ICSAICSA

ICSA - IDSICSA - IDS

ICSA - IDSICSA - IDS

System Security EngineeringCapability Maturity ModelSystem Security EngineeringCapability Maturity Model

SSE-CMM: “Describes the essential characteristics of an organization’s security engineering process that must exist to ensure good security engineering.”

Began as an NSA-sponsored effort in 1993. The model is a standard metric for security engineering

practices covering:the entire life cyclethe whole organizationinteractions with other organizations including acquisitions, system management, certification,…interactions with other disciplines

SSE-CMMSSE-CMM Intended to be used as a:

Tool for engineering organizations to evaluate their security engineering practices and define improvements to them.Standard mechanism for customers to evaluate a provider’s security engineering capability.Basis for security engineering evaluation organizations to establish capability-based confidences or assurance.

SSE-CMM Capability LevelsSSE-CMM Capability Levels1

PerformedInformally

2Planned &Tracked

3Well

Defined

0Not

Performed

4QualitativelyControlled

5Continuously

Improving

1Base PracticesPerformed

2Committing toperform

Planning performance

Disciplined performance

Tracking performance

Verifying performance

3Defining a standardprocess

Tailoring a standardprocess

Using data

Perform a definedprocess

4Establishingmeasurable quality goals

Determining processcapability toachieve goals

Objectively managingperformance

5Establishingquantitative processeffectiveness goals

Improving processeffectiveness

21 SSE-CMM Process Areas(some examples)21 SSE-CMM Process Areas(some examples) Administer Security Controls

Establish security responsibilitiesManage security configurationManage security awareness, training, and education programsManage security services and control mechanisms

Attack SecurityScope attackDevelop attack scenariosPerform attacksSynthesize attack results

Monitor System Security PostureAnalyze event recordsMonitor changesIdentify security incidentsManage security incident response

SummarySummary

What is the Importance and Significance of this material?

How does this topic fit into the subject of “Voice and Data Security”?