Audit security evaluation information assurance
This presentation is the property of its rightful owner.
Sponsored Links
1 / 65

Audit, Security Evaluation , Information Assurance PowerPoint PPT Presentation


  • 117 Views
  • Uploaded on
  • Presentation posted in: General

Audit, Security Evaluation , Information Assurance. Nicolas T. Courtois - U niversity C ollege L ondon. Audit. Audit. Major source of jobs Audit – several different types: Quality audits… In project management: advancement audits, In accounting: Audit checks the accounts

Download Presentation

Audit, Security Evaluation , Information Assurance

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


Audit security evaluation information assurance

Audit, Security Evaluation,Information Assurance

Nicolas T. Courtois - University College London


Audit security evaluation information assurance

Audit

Nicolas T. Courtois, December 2009


Audit

Audit

Major source of jobs

Audit – several different types:

  • Quality audits…

  • In project management: advancement audits,

  • In accounting: Audit checks the accounts

    • and compliance to certain rules such as nobody is claiming 200 % of his time,

  • Internal Audit:

    • compliance to the internal rules of an organization,

  • External Audit:

    • an authority checks compliance to laws, and regulations,

Nicolas T. Courtois, December 2009


It and audit

IT and Audit

In IT:

Certified Information Systems Auditor (CISA) – scope is the whole of IT, not only security…

In Information Security: Audit = analysis of past events in order to see if the security breaches have occurred or have been attempted.

Offline, after the facts… About security.

Nicolas T. Courtois, December 2009


Residual risk def

Residual Risk = def

what remains after defences are in place…

Nicolas T. Courtois, December 2009


Audit is needed

Audit is Needed

because of this residual risk.

Things are going to happen.

Sometimes it is a part of the whole system of defenses.

Certain security violations will be detected ONLY at a much later time. That’s all right if we can

  • trace the culprit,

  • cancel certain transactions,

  • revoke certain keys,

  • etc…

Nicolas T. Courtois, December 2009


Audit logs

Audit Logs

Example: In access control we do record:

  • subject requesting

  • object of the request

  • operation requested

  • time and date

  • location / IP address of the request

  • status of the request:

    • granted / denied,

    • physical resources used (like CPU time)...

Nicolas T. Courtois, December 2009


Why not more

Why Not More?

Choices are specific to each application.

If memory is critical, it is very important to log only the minimum, example: in bank cards.

Otherwise nowadays space if getting cheaper and cheaper… But even then

  • legal or contractual obligations

    • (e.g. credit card merchants are NOT allowed to store the CVC)

  • or privacy-friendly design considerations

  • “proportionality principles”

    will prevent us from logging too much information…

Nicolas T. Courtois, December 2009


Audit security evaluation information assurance

Intrusion Detection

Nicolas T. Courtois, December 2009


Intrusion detection

Intrusion Detection

Audit:

  • usually offline, after the facts

    Intrusion detection:

  • usually active, real time, online.

  • otherwise we speak about “passive intrusion detection”…

Nicolas T. Courtois, December 2009


Types of intrusion detection

Types of Intrusion Detection

  • Threshold-based

  • Anomaly-based,

  • Rule-based,

  • State transition-based,

Nicolas T. Courtois, December 2009


Most basic intrusion detection

Most Basic Intrusion Detection

Notion of “security events”

Nicolas T. Courtois, December 2009


Very basic example

Very Basic Example

Alarms

Nicolas T. Courtois, December 2009


Types of intrusion detection1

Types of Intrusion Detection

  • Threshold-based = detect abnormal use. Examples:

    • try 4 different PINs in an ATM,

      • the card will stop working forever

    • high CPU load, a lot of data sent out…

      Cons: false positives.

      (for other methods too…)

Nicolas T. Courtois, December 2009


Types of intrusion detection 2

Types of Intrusion Detection (2)

  • Anomaly-based:

    Defines profiles: what is the normal behavior in terms of

    • key security events

    • CPU/memory usage by a user

    • their timing

  • How to Measure the deviation?

    • Each profile will define acceptable intervals, otherwise an alarm will be raised.

      • Example: an employee of the bank is expected to do between 10 and 40 credit history checks per day in office, with time intervals of at least 10 minutes.

    • Can also use the time series model:

      • events occurring in circumstances where the historical probability is VERY low (say a credit check during the lunch break in a big French bank) will raise an alert.

  • Nicolas T. Courtois, December 2009


    Key latency control

    Key Latency Control

    • Powerful mechanism to detect anomalies in behavior of employees and to detect malware.

    Nicolas T. Courtois, December 2009


    Types of intrusion detection 2 3

    Types of Intrusion Detection (2,3)

    • Anomaly-based

      • Doesn’t require a lot of technical knowledge,

        • it is just doing stats on apples and bananas…

    • Rule-based, can be based on:

      • past experience of intrusions / breaches

      • Known system vulnerabilities / attacks

        Cons: require a lot of expert knowledge…

    Nicolas T. Courtois, December 2009


    Rule based example

    Rule Based - Example

    Information Flow Control

    • Can be applied where BLP model is applicable.

      • the key point is that maybe we don’t need to enforce a very strict policy, just create administrative alerts when it is violated..

    Nicolas T. Courtois, December 2009


    Types of intrusion detection 4

    Types of Intrusion Detection (4)

    • State transition-based:Require a sort of “security model” where:

      • Each state is characterized by assertions evaluating whether certain conditions are verified in the system.

      • For example, check if a user has the right privileges for a given object.

    Nicolas T. Courtois, December 2009


    Integrity control

    Integrity Control

    • Can be applied where Biba model with a dynamically changing levels, for example one of the low watermark policies is applicable.

      • it will be a state transition based intrusion detection mechanism.

    Nicolas T. Courtois, December 2009


    Audit security evaluation information assurance

    Information Assurance

    Nicolas T. Courtois, December 2009


    Security safety

    Security  Safety

    intentional damages...

    Nicolas T. Courtois, December 2009


    Scope 4 today

    Scope 4 Today

    Both:

    Safety and Security!

    Nicolas T. Courtois, December 2009


    Who to trust

    Who to Trust ?

    • pejorative: “Commercial security”; works if you believe it.

      Imagine a banker who wants to buy a product which is “secure”. How can he know it is secure? Security usually cannot be seen…

      Only the opposite is visible…

    Nicolas T. Courtois, December 2009


    What makes that a product is safe

    What Makes That a Product is Safe?

    • Inherent to the technology:

      • trains and lifts are inherently MUCH safer than cars…

      • bad news: computers + networks are by nature a security nightmare…

    • Market regulation:

      • example: make an airbag a legal obligation.

      • no legal obligations for computers yet…

        • “nobody is in charge”…

    Nicolas T. Courtois, December 2009


    Open source vs closed source

    Open Source vs. Closed Source

    Can be much easier to attack!

    will many people looking at source code will find the bugs?

    • bugs are VERY HARD to find,

      • people rarely get paid for that… much less hours spent…

    • security problems can be a result of a combination of:

      • code+compiler (e.g. buffer overflow)

      • code+hardware (side channel attacks on crypto)

      • good programmers + poor security background (prevalent)

    Nicolas T. Courtois, December 2009


    Boeing vs airbus

    Boeing vs. Airbus

    Airbus: [factories wide open to visitors]

    60 recorded crashes for 12 million flights.

    Boeing: [their factories are closed, security!]

    194 crashed for 35 million flights.

    Almost the same rate: 1 crash out of 0.2 M flights.

    Beware of statistical manipulation: how many crashes per mile? Per hour of flight? Deaths per hour*passenger? Etc…

    Cars vs. planes: similar rate of 1.5 death / 100 million miles traveled…

    Nicolas T. Courtois, December 2009


    Which model is better

    **Which Model is Better?

    Open and closed security are as more or less equivalent, more or less as secure:

    • opening the system helps both the attackers and the defenders.

      Ross Anderson: Open and Closed Systems are Equivalent (that is, in an ideal world). In Perspectives on Free and Open Source Software, MIT Press 2005, pp. 127-142.

    Nicolas T. Courtois, December 2009


    Airlines what they do

    Airlines: What they Do

    “High Assurance” industry,

    obsessed with safety since ever…

    What is Assurance?

    • Building confidence that systems meet the security criteria, based on application of “assurance” techniques:

      • design methodology

      • expert design analysis

      • assessment/testing

    • Estimate the likelihood that bad things will happen…

    Nicolas T. Courtois, December 2009


    Aviation vs computer software

    Aviation vs. Computer Software

    vs.

    have just changed, new threats…

    fast:

    ship it now, get it right for next release…

    should work 99% of the time

    upgrades:

    not done,

    bad users…

    failures:

    tolerated

    goals:

    mostly clear from the start

    slow speed:

    carefully designed, 10 years time to market, high quality

    testing:

    exhaustive tests

    maintenance:

    scheduled,

    certified technicians,

    pilots need a licence

    failures:

    EVERYTHING done to prevent ever happening again…

    + separation of duty

    Nicolas T. Courtois, December 2009


    Aviation

    Aviation:

    Possibly an example to follow?

    Maybe? Maybe not? Not clear.

    Assurance: Key ideas:

    • design a trusted engineering process:

      • classical “industrial” view: engineer the whole process of design+implem.+testing

      • even more modern version: create the right incentives for private business to solve all the problems for you…

    • codify best practices,

      • train engineers [e.g. at university]

      • train users of systems…

    Nicolas T. Courtois, December 2009


    Following the idea

    Following the Idea..

    What is Information Assurance? The Same.

    • Building confidence that systems meet the security criteria, based on application of “assurance” techniques:

      • design methodology

      • expert design analysis

      • assessment/testing

    • Estimate the likelihood that bad things will happen…

    Nicolas T. Courtois, December 2009


    Evidence based assurance

    Evidence-based Assurance

    Sullivan: there should be sufficient credible evidence that the system meets the requirements…

    Nicolas T. Courtois, December 2009


    Ross anderson

    Ross Anderson:

    “Fundamentally, assurance comes down to the question of whether capable, motivated people have beat up on the system enough.

    • But how do you define enough?

    • And how do you define the system?

    • How do you deal with people who protect the wrong thing, … out of date or plain wrong? …

    • allow for human failures?”

    Nicolas T. Courtois, December 2009


    Audit security evaluation information assurance

    Failures

    Nicolas T. Courtois, December 2009


    Attacks target

    Attacks Target

    attacker

    vulnerabilities

    threat potential attack scenario

    attack

    system

    target

    • defences

    • controls

    • countermeasures

    expectations, goals properties security policy=what is allowed/not (protection goals) if there is one

    Nicolas T. Courtois, December 2009


    Security failures

    Security Failures

    vulnerability

    • defences:

    • controls

    • countermeasures

    + attacker

    threat potential attack scenario

    security target:a more detailed specification of a set of means/protections to achieve the goals and a yardstick to evaluate if designers / implementers did a good job

    ActualAttack

    scenario

    security policy: what is allowed/not, protection goals

    protection profile:

    what needs to be protected … allowing comparison of very different products famous for omissions

    Nicolas T. Courtois, December 2009


    Types of failures sullivan

    Types of Failures [Sullivan]

    • Failure in design

      • omissions/mistakes in the spec

      • bad engineering /faulty design

    • Failure in implementation

      • hardware/software

    • Failure in operation

      • operator errors

      • willful misuse

      • random failures

        • hardware or comm/network malfunction

        • natural causes: “Acts of God”

      • failure in upgrade / maintenance

    Design Assurance

    Implementation Assurance

    Operational Assurance

    Nicolas T. Courtois, December 2009


    Design assurance

    Design Assurance

    requirements should determine the security policy,

    or security model == the space of possible security policies

    Nicolas T. Courtois, December 2009


    Policy assurance

    Policy Assurance

    Evidence that the set of security requirements is:

    • Complete:

      • Every situation is either “safe” or “unsafe”.

        • Ambitious. Are we sure we need this one?

    • Consistent:

      • Free of (formal) contradiction... We want it!

    • Technically Sound:

      • The policy captures what we wanted,

        • not like to Biba policy where all subjects are downgraded immediately, and everybody is secure by name… but not in meaningful way.

    Nicolas T. Courtois, December 2009


    Design assurance1

    Design Assurance

    Show that the policy requirements will be met…

    Nicolas T. Courtois, December 2009


    Implementation assurance

    Implementation Assurance

    Considerations

    • implemented correctly

    • Using tools and best practices used to avoid introducing extra implementation vulnerabilities (e.g. side channels, backdoors, etc…)

    • testing

    • proof of correctness? Hard.

    • document the product well!

    Nicolas T. Courtois, December 2009


    Operational assurance

    Operational Assurance

    • system should sustain the security policy requirements during

      • installation/configuration,

      • day-to-day operation

        • usability testing is needed to

      • upgrades/maintenance

    Nicolas T. Courtois, December 2009


    Following the idea1

    Following the Idea..

    What is Information Assurance?

    It is also basically a method to “argument”.

    • can I convince myself it is secure?

    Nicolas T. Courtois, December 2009


    Forwards and backwards

    Forwards and Backwards

    Nicolas T. Courtois, December 2009


    Life cycle assurance

    ***Life Cycle Assurance

    • Conception

      • focus on policy and requirements

    • Building

      • select mechanisms to enforce policies

        • give evidence that are appropriate

    • Deployment

      • provide mechanisms for delivery that assures integrity,

        • initial setup and key management

        • appropriate configuration

    • Fielded Product Life

      • update and patch mechanism

      • customer support

      • product decommissioning and end of life

    Nicolas T. Courtois, December 2009


    Audit security evaluation information assurance

    Orange Book, CC

    Nicolas T. Courtois, December 2009


    History

    History:

    1983-1999

    • Orange Book = Trusted Computer System Evaluation Criteria = TCSEC

      • designed for OS mostly… emphasis on confidentiality…

        1998-present

    • Common Criteria = ITSEC = ISO 15408

      • designed for “everything”

        Both deeply rooted in the military circles… DoD, NSA, GCHQ, etc…

        Both give a single linear scale – right answer:

    Nicolas T. Courtois, December 2009


    Orange book dc

    Orange Book DC

    Division D: Minimal Protection

    Division C: Discretionary Protection

    C1- DAC, Identification and Authentication, protected from external tampering, …

    C2 – Controls access to objects, object reuse, has auditing, more security testing

    Nicolas T. Courtois, December 2009


    Orange book b

    Orange Book B

    Division B: Mandatory Protection

    B1 - labeled security, MAC for named objects, informal security policy

    B2 - structured protection: consistent formal security policy/model; MAC for all objects, labeling; trusted path; least privilege; covert channel analysis, admin tools, configuration management, pen-tested

    B3 - structured design, security domains, full reference monitor, increases trusted path requirements, constrains code development, real-time monitoring, good documentation,

    Nicolas T. Courtois, December 2009


    Orange book a

    Orange Book A

    Division A: Verification Protection

    A1As B3, but designed from the scratch with formal methods…

    Nicolas T. Courtois, December 2009


    Common criteria

    Common Criteria

    • 1998: A Common Criteria Recognition Agreement:

      • US, UK, Canada, France, Germany

    • joined in 2002 by:

      • Australia, Finland, Greece, Israel, Italy, Netherlands, New Zealand, Norway, Spain, Sweden; India, Japan, Russia, South Korea

    • later became an international standard ISO/IEC 15408 http://www.commoncriteria.org/

    Nicolas T. Courtois, December 2009


    Common criteria1

    Common Criteria

    What does it do?

    describes a language and a framework where:

    • the security requirements will be specified,

      • goals can be claimed to be achieved,

      • and this can be evaluated

        • claims can later be shown to hold or shown not to hold!

    Nicolas T. Courtois, December 2009


    Common criteria concepts

    Common Criteria Concepts

    • Target Of Evaluation (TOE): the product or system that is the subject of the evaluation.

    • Protection Profile (PP): a document that identifies security requirements relevant to a user community for a particular purpose.

    • Security Target (ST): a document that identifies the security properties one wants to evaluate against

    • Evaluation Assurance Level (EAL) - a numerical rating (1-7) reflecting the assurance requirements fulfilled during the evaluation.

    Nicolas T. Courtois, December 2009


    Audit security evaluation information assurance

    ToE

    • Target Of Evaluation (TOE): the product or system that is the subject of the evaluation.

    Nicolas T. Courtois, December 2009


    Audit security evaluation information assurance

    PP

    • Protection Profile (PP): a document that identifies security requirements relevant to a user community for a particular purpose.

      • an implementation-independent set of security requirements for a category of products or systems that meet specific consumer needs”

      • a more detailed specification of a set of means/protections to achieve the goals

      • and a yardstick to evaluate if designers / implementers did a good job

      • subject to review and certified

    Nicolas T. Courtois, December 2009


    Pp example

    PP - Example

    • Controlled Access PP == CAPP_V1.d

      • Security functional requirements

        • Authentication,

        • User Data Protection,

        • Prevent Audit Loss

      • Security assurance requirements

        • Security testing,

        • Admin guidance,

        • Life-cycle support, …

      • Assumes non-hostile and well-managed users

      • Does not consider malicious system developers

    Nicolas T. Courtois, December 2009


    Audit security evaluation information assurance

    ST

    • Security Target (ST): a document that identifies the security properties one wants to evaluate against.

      • “a set of security requirements and specifications to be used for evaluation of an identified product or system”

      • describes specific security functions and mechanisms

      • allowing comparison of very different products

    Nicolas T. Courtois, December 2009


    Common criteria certificates

    Common Criteria Certificates

    • CESG at GCHQ

      • Communications-Electronics Security Group at Government Communications Headquarters

        => Common Criteria Scheme

    Nicolas T. Courtois, December 2009


    Eal evaluation assurance level

    EAL = Evaluation Assurance Level

    commercial

    • EAL1: Functionally Tested

      • no need disclose the design/sources to government agencies…

  • EAL2: Structurally Tested

    • 6 months, 150 K$

  • EAL3: Methodically Tested and Checked

  • EAL4: Methodically Designed, Tested, and Reviewed

    • EAL4+: flaw remediation, better crypto, etc…

    • 24 months, 150 K$ - 2.5 M$ per product

      • Ms. Windows 2000 source certified EAL4+ for an undisclosed amount

  • EAL5: Semi-formally Designed and Tested

  • EAL6: Semi-formally Verified Design and Tested

  • EAL7: Formally Verified Design and Tested

  • military

    Nicolas T. Courtois, December 2009


    Microsoft and eal4

    Microsoft and EAL4+

    Schneier on Security

    Microsoft Windows Receives EAL 4+ Certification

    Microsoft announced that all the products earned the EAL 4+ (Evaluation Assurance Level), which is the highest level granted to a commercial product.

    The products receiving CC certification include Windows XP Professional with Service Pack 2 and Windows XP Embedded with Service Pack 2. Four different versions of Windows Server 2003 also received certification.

    Is this true?

    ...director of security engineering strategy at Microsoft Steve Lipner said the certifications are a significant proof point of Redmond's commitment to creating secure software.

    Bad publicity for EAL 4+…

    Target of evaluation: switch the network off.

    Nicolas T. Courtois, December 2009


    Cc recognition

    CC Recognition

    Only EAL 1-5 are recognized by other countries…

    Levels 6-7 are closed military and national stuff…

    Nicolas T. Courtois, December 2009


    Cc criticism

    CC Criticism

    • people that do these evaluations are more or less the national military or national intelligence agencies (GCHQ, NSA), but also US NIST,

      • all willing to help defend the national industry…

      • but also conflicting interests (signals intelligence interception etc.)

    • top-down culture, not listening to the industry

    • slow, product is now obsolete by the time you go through it…

    • bureaucratic process, mostly about writing things in a certain way…

      • used to be a major source of jobs for cryptologists…

    • there is no evidence that EAL made products more secure in practice.

      • Ross Anderson suggests that some governments were permissive/easy on business, or maybe cynical: certified the products they could break…

    • evaluation depends on PP, this one is not too broad,

      • chosen by the vendor in his favor.

      • should be the one required by the customer!

    Nicolas T. Courtois, December 2009


    Good points

    Good Points

    Some countries such as France (DCSSI) have developed extra evaluations and force stronger mechanisms, especially in cryptography.

    • products can be evaluated as “high level” (niveau élevé).

    • It is recognized that CC contributed a lot for developing MUCH stronger cryptography used in the industry of countries such as France, Germany, UK etc…

    Nicolas T. Courtois, December 2009


    Cc decline

    CC: Decline?

    • today, since 2000 or so..

      • the profitability of security industries suffered,

      • less ‘legal’ reasons to ever evaluate products…

      • time to market became very important,

      • got some bad publicity

  • since 2000 CC evaluations are less widely used

    (banks still continue: eg bank cards and terminals…)

    New U.S. DoD strategy: COTS = Commercial Off The Shelf,

    • can add custom configuration / setup

  • Nicolas T. Courtois, December 2009


  • Login