Você está na página 1de 47

1.

SECURITY ENGINEERING
Chandra Prakash Assistant Professor LPU

Course Overview
Textbook:
Security Engineering, Ross J Anderson, Wiley + Biometrics for Network Security, Paul Reid, Prentice Hall ( Research Papers literature)

Goal: thorough understanding of information security


technology

Related Sites
http://freevideolectures.com/Course/2383/Computer-SystemEngineering/18 Book Page
http://www.cl.cam.ac.uk/~rja14/book.html

Aims
Give you a thorough understanding of information security technology Policy (what should be protected) Mechanisms (cryptography, electrical engineering, ) Attacks (malicious code, protocol failure ) Assurance how do we know when were done? How do we make this into a proper engineering discipline?

Objectives
By the end of the course, you should be able to tackle an information protection problem by drawing up a threat model, formulating a security policy, and designing specific protection mechanisms to implement the policy.

Objectives of the Chapter


Introduction Framework and Examples related to role of security

Software systems Objectives:


Engineered with reliable protection mechanisms. Deliver the expected value of the software to their customers Importance of Secured Systems:
In applications where the quality of service depends on data confidentiality, data integrity, and protection against denial-of-service attack, the need for secure networks is evident.

Objectives
Software Engg
Software Engineering Usability Performance Timely Completion Reliability Flexibility

Security Engg
customized access control and authentication based on the privilege levels of users, traceability and detection, accountability, non-repudiation, privacy, confidentiality, and integrity

Objectives (contd)
Current Software Engineering processes do not provide enough support to achieve security goals. Unification of the process models of Software engineering and Security Engineering is required.

Security Engineering objectives are to design a software system that meets both security objectives and application objectives

we are entering a brave new world ...

The digital world behaves differently to the physical world Everything in the digital world is made of bits Bits have no uniqueness Its easy to copy bits perfectly

Nothing is secure in the digital world

Therefore, if you have something, I can copy it Information Privileges Identity Media Software Digital money Much of information security revolves around making it hard to copy bits

Objectives
To introduce issues that must be considered in the specification and design of secure software To discuss security risk management and the derivation of security requirements from a risk analysis To describe good design practice for secure systems development. To explain the notion of system survivability and to introduce a method of survivability analysis.

Security engineering
Tools, techniques and methods to support the development and maintenance of systems that can resist malicious attacks that are intended to damage a computer-based system or its data. A sub-field of the broader field of computer security. Security engineering is about building systems to remain dependable in the face of malice, error and mischance. As a discipline, it focuses on the tools, processes and methods needed to design, implement and test complete systems, and to adapt existing systems as their environment evolves.

Design Hierarchy
What are we trying to do? How?
Policy

Protocols

With what?

Hardware, crypto,

System layers

Application Reusable c omponents and libraries Middleware Database management Generic, shared applications (Browsers , e--mail, etc ) Operating S y s tem

Application/infrastructure security
Application security is a software engineering problem where the system is designed to resist attacks. Infrastructure security is a systems management problem where the infrastructure is configured to resist attacks.

Security Concepts
Term Asset Exposure Definition A system resource that has a value and has to be protected. The possible loss or harm that could result from a successful attack. This can be loss or damage to data or can be a loss of time and effort if recovery is necessary after a security breach. A weakness in a computer-based system that may be exploited to cause loss or harm. An exploitation of a systems vulnerability. Generally, this is from outside the system and is a deliberate attempt to cause some damage. Circumstances that have potential to cause loss or harm. You can think of these as a system vulnerability that is subjected to an attack. A protective measure that reduces a systems vulnerability. Encryption would be an example of a control that reduced a vulnerability of a weak access control system.

Vulnerability Attack

Threats

Control

Examples of security concepts


Term Asset Exposure Definition The records of each patient that is receiving or has received treatment. Potential financial loss from future patients who do not seek treatment because they do not trust the clinic to maintain their data. Financial loss from legal action by the sports star. Loss of reputation. A weak password system which makes it easy for users to set guessable passwords. User ids that are the same as names. An impersonation of an authorised user. An unauthorised user will gain access to the system by guessing the credentials (login name and password) of an authorised user. A password checking system that disallows passwords that are set by users which are proper names or words that are normally included in a dictionary.

Vulnerability

Attack Threat

Control

Security Requirements
Everything you have been taught so far in engineering revolves around building dependable systems that work
Typically engineering efforts are associated with ensuring something does happen e.g. John can access this file

Security engineering traditionally revolves around building dependable systems that work in the face of a world full of clever, malicious attackers
Typically security has been about ensuring something cant happen. e.g. the Chinese government cant access this file.

Reality is far more complex

Security requirements differ greatly between systems

Security Vs Dependability
Dependability = reliability + security Reliability and security are often strongly correlated in practice But malice is different from error! Reliability: Bob will be able to read this file Security: The Chinese Government wont be able to read this file Proving a negative can be much harder

Why do systems fail?


Systems often fail because designers : Protect the wrong things Protect the right things in the wrong way Make poor assumptions about their systems Do not understand their systems threat model properly Fail to account for paradigm shifts (e.g. the Internet) Fail to understand the scope of their system

Framework
Security Engineering Analysis Framework

Framework
Policy: what youre supposed to achieve. Mechanism: the ciphers, access controls, hardware tamperresistance and other machinery that you assemble in order to implement the policy. Assurance: the amount of reliance you can place on each particular mechanism. Incentive: the motive that the people guarding and maintaining the system have to do their job properly, and also the motive that the attackers have to try to defeat your policy

Bank security requirements


Core of a banks operations is its bookkeeping system
Most likely threat: internal staff stealing petty cash Goal: highest level of integrity

ATMs
Most likely threat: petty thieves Goal: authentication of customers, resist attack

High value transaction systems


Most likely threat: internal staff, sophisticated criminals Goal: integrity of transactions

Internet banking
Most likely threat: hacking the website or account Goal: authentication and availability

Safe
Threat: physical break-ins, stealing safe Goal: physical integrity, difficult to transport, slow to open

Military communications
Electronic warfare systems
Objective: jam enemy radar without being jammed yourself Goal: covertness, availability Result: countermeasures, countercountermeasures etc.

Military communications
Objective: Low probability of intercept (LPI) Goal: confidentiality, covertness, availability Result: spread spectrum communications etc.

Compartmentalisation
Objective example: logistics software- administration of boot polish different from stinger missiles Goal: confidentiality, availability, resilience to traffic analysis?

Nuclear weapons command & control


Goal: prevent weapons from being used outside the chain of command

Hospital security requirements


Use of web based technologies
Goal: harness economies of the Internet (EoI ) e.g. online reference books Goal: integrity of data

Remote access for doctors


Goal: authentication, confidentiality

Patient record systems


Goal: nurses may only look at records of patients who have been in their ward in the last 90 days Goal: anonymity of records for research

Paradigm shifts introduce new threats


Shift to online drug databases means paper records are no longer kept Results in new threats on
availability e.g. denial of service of network integrity e.g. malicious temporary tampering of information

Risk Analysis
Risk Impact Matrix
Impact Extreme Certain Likely Likelihood Moderate Unlikely Rare 1 2 3 4 5 6 7 1 1 2 3 4 High 1 2 3 4 5 Medium 2 3 4 5 6 Low 3 4 5 6 7 Negligible 4 5 6 7 7

severe must be managed by senior management with a detailed plan high detailed research and management planning required at senior levels major senior management attention is needed significant management responsibility must be specified moderate manage by specific monitoring or response procedures low manage by routine procedures trivial unlikely to need specific application of resources

Axioms of information security


All systems are buggy The bigger the system the more buggy it is Nothing works in isolation Humans are most often the weakest link Its a lot easier to break a system than to make it secure

A system can be..


A product or component
e.g. software program, cryptographic protocol, smart card

plus infrastructure
e.g. PC, operating system, communications

plus applications
e.g. web server, payroll system

plus IT staff plus users and management plus customers and external users plus partners, vendors plus the law, the media, competitors, politicians, regulators

Aspects of security
Authenticity Proof of a messages origin Integrity plus freshness (i.e. message is not a replay) Confidentiality The ability to keep messages secret (for time t) Integrity Messages should not be able to be modified in transit Attackers should not be able to substitute fakes Non-repudiation Cannot deny that a message was sent (related to authenticity)

Availability Guarantee of quality of service (fault tolerance)


Covertness Message existence secrecy (related to anonymity)

Passive attacks
Those that do not involve modification or fabrication of data Examples include eavesdropping on communications Interception
An unauthorised party gains access to an asset Release of message contents: an attack on confidentiality Traffic analysis: an attack on covertness

Active Attacks
Those which involve some modification of the data stream or creation of a false stream Fabrication
An unauthorised party inserts counterfeit objects into the system Examples include masquerading as an entity to gain access to the system An attack on authenticity

Interruption
An asset of the system is destroyed or becomes unavailable or unusable Examples include denial-of-service attacks on networks An attack on availability

Modification
An unauthorised party not only gains access to but tampers with an asset Examples include changing values in a data file or a virus An attack on integrity

Definitions
Secrecy
A technical term which refers to the effect of actions to limit access to information

Confidentiality
An obligation to protect someone or some organization's secrets

Privacy
The ability and/or right to protect the personal secrets of you or your family; including invasions of your personal space Privacy does not extend to corporations

Anonymity
The ability/desire to keep message source/destination confidentiality

Trust
A trusted system is one whose failure can break security policy. A trustworthy system is one which wont fail. A NSA employee caught selling US nuclear secrets to a foreign diplomat is trusted but not trustworthy. In information security trust is your enemy.

Trust is your enemy


You cannot trust software or vendors
They wont tell you their software is broken They wont fix it if you tell them

You cannot trust the Internet nor its protocols


Its built from broken pieces Its a monoculture; something breaks everything breaks It was designed to work, not be secure

You cannot trust managers


They dont want to be laggards nor leaders Security is a cost centre, not a profit centre!

You cannot trust the government


They only want to raise the resource game to their level

You cannot trust your employees or users


They are going to pick poor passwords They are going to mess up the configuration and try to hack in They account for 90% of security problems

Trust is your enemy


You cannot trust your peers
They are as bad as you

You cannot trust algorithms nor curves


Moores law does not keep yesterdays secrets Tomorrow they might figure out how to factor large numbers Tomorrow they might build a quantum computer

You cannot trust the security community


They are going to ridicule you when they find a problem They are going to tell the whole world about it

You cannot trust information security


Its always going to be easier to break knees than break codes

You cannot trust yourself


You are human One day you will screw up

Tenet of information security


Security through obscurity does not work Full disclosure of the mechanisms of security algorithms and systems (except secret key material) is the only policy that works Kirchoffs Principle: For a system to be truly secure, all secrecy must reside in the key If the algorithms are known but cannot be broken, the system is a good system If an algorithm is secret and no-one has looked at it, nothing can be said for its security

Case Study
Voting Do electronic voting machines meet the reasonable expectations of society to provide a technology that is trustworthy and cost effective?

Trustworthy: Worthy of confidence; dependable [Websters on-line]

Expectations of Voting
Vote is by secret ballot
Confidentiality

The vote should be correctly tallied; all votes cast should be counted in the election
Integrity

Every eligible voter who presents themselves at the polling place should be able to vote
Availability

Security or Computer Security?


Are the expectations of integrity, confidentiality, and availability specific to computers?
Can the properties of the computer system be considered independently of its use?

Voting: Policies and Mechanisms


Who can vote?
Policy

requirements for eligibility


Must be a citizen residing in the precinct Must be of voting age
Mechanism

Administrative requirements to register to vote


Fill out an application Present evidence of residence (can be by mail or fax)

Voting Mechanisms
Paper ballot in a ballot box (or mail)
May be implemented as a scan form

Punch cards Mechanical voting machines Direct Recording Electronic Voter-verifiable paper audit trail

Evaluating mechanisms
How do we evaluate these options? Evaluation must be relevant to a threat model

Voting threat models


Correlating ballot with voter Ballot stuffing Casting multiple votes Losing ballot boxes Ballot modification Incorrect reporting of results Denial of access to polls Vandalism Physical intimidation

Key points
Security engineering is concerned with how to develop systems that can resist malicious attacks Security threats can be threats to confidentiality, integrity or availability of a system or its data Design for security involves architectural design, following good design practice and minimizing the introduction of system vulnerabilities Key issues when designing a secure architecture include organizing the structure to protect assets and distributing assets to minimize losses General security guidelines sensitive designers to security issues and serve as review checklists

Morals of the story


Nothing is perfectly secure

Information security is a resource game


Nothing works in isolation Know your system Know your threat model Trust is your enemy

All systems can and will fail


Humans are usually the weakest link Attackers often know more about your system than you do

References
Stallings

Interesting Websites
http://www.csl.sri.com/users/neumann/illustrative.html http://www.packetstormsecurity.org http://www.securityfocus.com http://www.digicrime.com http://www.cryptome.org http://www.phrack.org http://www.eff.org

Você também pode gostar