1 / 56

Security Engineering

Security Engineering. Overview. Software Engineering Requirements Engineering (Security) Common Criteria early stages Threat / Risk Analysis Security Objectives / Requirements / Functions Example(s) : Public Key Infrastructures, E-Voting. Software (Security) Engineering.

mariko
Télécharger la présentation

Security Engineering

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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. SecurityEngineering

  2. Overview • Software Engineering • Requirements Engineering (Security) • Common Criteria • early stages • Threat / Risk Analysis • Security Objectives / Requirements / Functions • Example(s) : Public Key Infrastructures, E-Voting

  3. Software (Security) Engineering • My own experience is that developers with a clean, expressive set of specific security requirements can build a very tight machine. They don‘t have to be security gurus, but they have to understand what they‘re trying to build and how it should work. - Rick Smith • One of the most important problems we face today, as techniques and systems become more and more pervasive, is the risk of missing that fine, human point that may well make the difference between success and failure, fair and unfair, right and wrong... no IBM computer has an education in the humanities. • - Tom Watson • Management is that for which there is no algorithm. Where there is an algorithm, it‘s administration. • - Roger Needham Taken from Anderson: Security Engineering, Wiley

  4. Security Issues (according to Common Criteria) Owners wish to minimize to reduce countermeasures impose value that may be reduced by that may possess vulnerabilities may be aware of Threat agents that exploit leading to risk to give rise to that increase threats to assets wish to abuse and/or may damage

  5. Security Engineering • There is (up to now) no particular (process) model for security engineering. • Consider instantiations of general models. • Emphasis is on the “early stages” : requirements engineering • Techniques discussed before as parts of a development • processes. • Evaluation by (trusted) third parties.

  6. Waterfall Model Taken from Sommerville : Softwareengineering, Addison-Wesley

  7. The Spiral Model (Boehm)

  8. Process Visibility • Deliverable oriented processes • Stages of the development process and their deliverables (artefacts) • Artefacts: documents, reports, reviews, ... • Description techniques associated with artefacts : • natural language text • diagrams • semi-formal • formal • Quality Criteria: requirements for artefacts (and development methods (“assurance levels”)

  9. informal definition abstract specification requirements refinement proofs program mathematicalnotions Software-Development

  10. Common Criteria (CC)

  11. Common Criteria (CC) • Many consumers of IT lack the knowledge, expertise or resources necessary to judge whether their confidence in the security of their IT products or systems is appropriate, and they may not wish to rely solely on the assertions of the developers. • Consumers may therefore choose to increase their confidence in the security measures of an IT product or system by ordering an analysis of its security (i.e. a security evaluation). • The CC can be used to select the appropriate IT security measures and it contains criteria for evaluation of security requirements.

  12. Common Criteria Developers National Institute of Standards and Technology, National Security Agency US Communications Security Establishment Canada Communications-Electronic Security Group UK Bundesamt fur Sicherheit in der Informationstechnik Germany Service Central de la Securite des Systemes d’Information France National Institute of Standards and Technology National Security Agency Netherlands

  13. Assurance Techniques Evaluation produce assurance gives evidence of Owners giving confidence require countermeasures that risk minimise to assets Assurance / Evaluation • Der Anwender des FairPay Vorgehensmodells erhält • ein System mit vorhersagbaren Sicherheitseigenschaften und • ein FairPay Label !? • FairPay-Label • Was kann das sein? • Wie verhält es sich zu anderen Standards?

  14. Common Criteria (CC) • The CC is useful as a guide for the development of products or systems with IT security functions and • for the procurement of commercial products and systems with such functions. • During evaluation, such an IT product or system is known as a Target of Evaluation (TOE) . • Such TOEs include, for example, operating systems, computer networks, distributed systems, and applications.

  15. Common Criteria (CC) • The CC addresses protection of information from unauthorised disclosure, modification, or loss of use. The categories of protection relating to these three types of failure of security are commonly called confidentiality, integrity, and availability, respectively. • The CC may also be applicable to aspects of IT security outside of these three.

  16. Common Criteria (CC) • The CC concentrates on threats to that information arising from human activities, whether malicious or otherwise, but may be applicable to some non- human threats as well. • In addition, the CC may be applied in other areas of IT, but makes no claim of competence outside the strict domain of IT security.

  17. Evaluation – Certification Scheme

  18. CC Development Model

  19. Process

  20. Process

  21. TOE Description (Example) • TOE Summary • The TOE concerned is a product for carrying out online elections. The TOE meets the Common Criteria for IT security of online election systems. Votes are cast remotely through a client device of the voter’s choosing and are stored on the election server. The vote count takes place on the election server after the final whistle. • It relates to elections where votes must be cast secretly, but who has cast a vote does not have to be kept secret. It also addresses elections where it is intended that no voter may no more than one vote; where the voters must be prevented from proving their choice of candidate; and where the calculation of intermediate results during the election must be prevented. Amendments to the list of eligible voters during the polling period are not dealt with.

  22. TOE Description : Example • The TOE’s Task • Voting consists of three phases: election preparation, polling period including the vote count and archiving of the online election system as well as the data created by the TOE, such as ballot and log data. Here we consider one TOE for the polling period including the vote count. • In the election preparation, the election data are created and, where applicable, corrected; hence before the polling period has begun, the ballot box is empty, the final version of the election data is integrated in the TOE. • The polling period begins when the election committee starts the online election on the initialised server-side TOE. Now the votes can cast their votes. The election committee blows the final whistle at the specified time on the server-side TOE. Next, the vote count takes place. The first step of this is to decide how many valid, and how many spoiled, votes are stored in the ballot box, followed by the count of the valid votes. • Storing includes, amongst others, the retention of the online software, the polling period and the result data. • The process sequence for the polling period including the vote count is described in the next chapter.

  23. TOE Description: Example Voter‘s View Start of Client-TOE Login voter stops voting process Id and Authentication data Authentication voter stops voting process error message: not eligible already voted voter gets ballot Client-TOE shows ballot voter stops voting process voter inputs vote Client-TOE shows vote voter stops voting process new choice voter confirms vote Client-TOE shows acknowledge end of voting process

  24. TOE Notions Cast vote When a vote has been effectively and irrevocably deposited in the ballot box, it is a cast vote. Authentication data Data that is stored for each voter and checked to verify whether he is eligible to vote, for example the hash value of the TAN or the voter’s certified public key. Authentication characteristic A characteristic of the voter that he uses to authenticate himself to the TOE, for example a TAN or smart card which stores his secret key. Client-side TOE Software that must be installed on an end device to allow a user to cast a vote from it. Client Device The device on which the client-side TOE is installed and which establishes a connection to the network. Result The tabulation of all valid votes stored in the ballot box. Also called ‘election result’. Identification data (unlike ‘authentication’, this term does not distinguish between the voter’s authentication characteristic and the authentication characteristic stored in the list of eligible voters; instead, this term refers to both) On the one hand a characteristic that the voter possesses and uses to identify himself on the TOE, for example a member number, a name, a date of birth or an address. On the other hand the data stored in the list of eligible voters that refer to a voter and which allow him to be identified unmistakeably. Content of the authentication message For the authentication process we distinguish between the authentication characteristic, which resides with the voter, the authentication data, which is on the list of eligible voters, and the content of the authentication message, which the voter sends to the election server in order to check for eligibility to vote. This can be, for example, a signed message that matches neither the authentication characteristic nor the authentication data.

  25. TOE Notions Cast vote When a vote has been effectively and irrevocably deposited in the ballot box, it is a cast vote. Authentication data Data that is stored for each voter and checked to verify whether he is eligible to vote, for example the hash value of the TAN or the voter’s certified public key. Authentication characteristic A characteristic of the voter that he uses to authenticate himself to the TOE, for example a TAN or smart card which stores his secret key. Client-side TOE Software that must be installed on an end device to allow a user to cast a vote from it. Client Device The device on which the client-side TOE is installed and which establishes a connection to the network. Result The tabulation of all valid votes stored in the ballot box. Also called ‘election result’. Identification data (unlike ‘authentication’, this term does not distinguish between the voter’s authentication characteristic and the authentication characteristic stored in the list of eligible voters; instead, this term refers to both) On the one hand a characteristic that the voter possesses and uses to identify himself on the TOE, for example a member number, a name, a date of birth or an address. On the other hand the data stored in the list of eligible voters that refer to a voter and which allow him to be identified unmistakeably. Content of the authentication message For the authentication process we distinguish between the authentication characteristic, which resides with the voter, the authentication data, which is on the list of eligible voters, and the content of the authentication message, which the voter sends to the election server in order to check for eligibility to vote. This can be, for example, a signed message that matches neither the authentication characteristic nor the authentication data.

  26. TOE Notions Confirmation After casting a vote, the voter receives confirmation that his vote has been stored, that’s to say the server-side TOE sends the client-side TOE an appropriate message and the client-side TOE then informs the voter; generally via an appropriate alert on the screen. Server-side TOE A piece of software that is installed on the server during the election. Vote casting The final and irrevocable depositing and storage of an vote in the ballot box. Vote count The action whose output is the (election) result. Vote record A vote that is prepared for transport and/or storage (e.g. in encrypted form). Vote (semantic) Content of a filled-out ballot that represents a voter’s will. Ballot (syntax) Displayed form (corresponds to a paper ballot). Can be empty or filled out. Ballot data include candidates list, as well as further information required by the TOE in order to display the ballot (e.g.:details to be displayed on the ballot, information about the layout of the ballot). Other information as required. SOF (strength of function) A way of characterising a TOE security function in terms of the smallest outlay required to circumvent it through a direct attack on its constituent security mechanisms. Unauthorised voter A person claiming to be a voter, fraudulently, who tries to cast one or more votes. This person does not appear on the list of eligible voters.

  27. TOE Notions Spoilt votes The opposite of valid votes, these votes are ignored when evaluating the result. The rules according to which a vote is deemed void are set out in the particular voting laws. An example of this would be where the voter has chosen too many candidates. Ballot box The ballot box is the collection of all cast vote records. Election result See glossary item ‘result’. Voter A person who appears in the list of eligible voters: both voters eligible to vote as well as voters ineligible to vote. Voter eligible to vote A voter who has not yet cast a vote. Voter ineligible to vote A voter who has already cast a vote. Index of voters All lists of eligible voters combined. (The index of voters is often identical to the list of eligible voters.) List of eligible voters List of all people entitled to cast a vote in the current election. List of eligible voters with authentication data As well as voter specific identification data, this also contains authentication data.

  28. TOE Notions Election data These data are saved and secured from manipulation during preparation for the election: ballot data list of eligible voters with authentication data final whistle time Polling period From the start of the online election until the election committee blows the final whistle. Polling period data These are the data that are saved and secured from manipulation at the blowing of the final whistle : ballot data the list of eligible voters as well as all data associated with it as well as that created during the election (e.g. comments about the casting of votes). contents of the ballot box logs Final whistle The end of the election is reached when the election committee blow the whistle at the server-side TOE. No further voters can log on to the server-side TOE and no more votes are stored in the ballot box. Final whistle time During the election preparation, the planned time at which the online election will end is defined. This is referred to as ‘final whistle time’. Voting process Includes all phases that a voter goes through: election eligibility test, receipt of a ballot, filling out/correcting a ballot, display of the vote, vote casting, confirmation.

  29. TOE Notions Election server Server on which the server-side TOE is installed. Election organiser Group of persons that organises a particular election. Election committee As well as the political/organisational election committee that assumes the political and organisational responsibility for the online election and carries it out, this term includes any election committee support staff who can start, rerun and end the online election or have general access to the election server. Election system All factors – hardware, software, communication, voters, organisational measures, elections committee, system administration – that influence the election. Access (to elections server) “Point or path that leads into a room or to a place” (Duden guide to German usage) – in this case, the elections server is the room or the place. Access (to the TOE) “[electronic data processing] the locating of data that is stored on the storage device.“ (see Wahrig German dictionary) – here: TOE as data and election server as storage device. Entry (to the rooms) In this case, entry to the room where the elections server is. Intermediate result The evaluation of cast votes during the election. Cache Storage of votes that have not been irrevocably cast and that can still be changed, e.g. on the client device or outside the ballot box on the server-side TOE. (This does not include cacheing during transmission in the technical sense.)

  30. Assets: Example Data to be protected content of the authentication message authentication data identification data ballot data vote vote record confirmation polling period data ballot box voter data list of eligible voters log data result

  31. Environment • The security environment includes all the laws, organizational security policies, customs, expertise and knowledge that are determined to be relevant. • It thus defines the context in which the TOE is intended to be used. • The security environment also includes the threats to security that are, or are held to be, present in the environment.

  32. Assumptions • A statement of assumptions which are to be met by the environment of the TOE in order for the TOE to be considered secure. • This statement can be accepted as axiomatic for the TOE evaluation.

  33. Environment :Example A.ClientDevice: The voter acts responsibly in securing the client device. It is assumed that each voter that installs or uses the client-side TOE does so in such a way that the client device can neither observe nor influence the vote casting process. This includes the assumption that the voter not manipulate his client device. A.ElectionServer: Protection of the election server against attacks that originate from the insecure network is provided.

  34. Assumptions : Example • Information about intended use • A.Interface: It is assumed that the election data are properly and correctly installed on the TOE at the beginning of the polling period; that the ballot box is empty; that the election preparation phase has been correctly carried out and that the TOE is correctly initialised. • A.Observation: The voter ensures that nobody is watching him while he votes. • A.ElectionCommittee: The election committee accesses no data other than that on the TOE; i.e., it uses only the functions made available by the TOE. • A.AuthenticationData: The voter knows how to deal with his means of identification and authentication and is consistent in doing so; in particular that he doesn’t allow them to fall into the hands of others.

  35. Threats • A statement of threats to security of the assets would identify all the threats perceived by the security analysis as relevant to the TOE. • The CC characterizes a threat in terms of a threat agent, a presumed attack method, any vulnerabilities that are the foundation for the attack, and identification of the asset under attack.

  36. Risk • An assessment of risks to security would qualify • each threat with an assessment of the likelihood of such a threat developing into an actual attack, the likelihood of such an attack proving successful, and the consequences of any damage that may result.

  37. Threats: Example • T.Unauthorised voter: An unauthorised voter or a voter ineligible to vote casts a vote on the client-side TOE. • Motivation: he wants to manipulate the election result. • Attack methods: direct • Opportunities: active • Exploited weakness: authentication process • Target data: vote

  38. Threats: Example • T.SecretMessage: A network attacker intervenes directly in the network in order to read messages relating to the online election while they are in transmission. • Motivation: • (a) He can breach the secrecy of the election by linking votes to voters. • (b) He can extract identification relating to individuals. • (c) Using the content of the authentication message, he can masquerade as a voter and cast a vote in the name of this voter. By doing this he can manipulate the result of the election. • (d) By reading and summing the individual votes, he can calculate intermediate results. • Attack methods: direct • Opportunities: passive • Exploited point of attack: communication network • Target data: (a) vote, (b) identification data, content of the authentication message, (c) vote, (d) vote

  39. Organizational Policies • A statement of applicable organizational security policies would identify relevant policies and rules. • For an IT system, such policies may be explicitly • referenced, whereas for a general purpose IT product or product class, working assumptions about organizational security policy may need to be made.

  40. Organizational Policies: Example This description of the organisational security policies specifies the policies and rules in accordance with which the TOE must operate. Each statement is presented such that it may be used to determine clear security goals. P.Cancel: The voter must be able to interrupt the voting process on the TOE and to retain his right to vote when doing so. P.EndElection: To prevent accidental, premature blowing of the final whistle, the election committee receives notification if it wants to end the election before the final whistle time. The election committee is still able to blow the final whistle prematurely. P.afterPP-Ballot box: After the final whistle, no more votes will be accepted.

  41. Objectives • The results of the analysis of the security environment could then be used to state • the security objectives that counter the identified threats and address identified organizational security policies and assumptions. • The security objectives should be consistent with the stated operational aim or product purpose of the TOE, and any knowledge about its physical environment.

  42. Objectives • The intent of determining security objectives is to address all of the security concerns and to declare which security aspects are either addressed directly by the TOE or by its environment. • This categorization is based on a process incorporating engineering judgment, security policy, economic factors and risk acceptance decisions.

  43. Objectives • The security objectives for the environment would be implemented within the IT domain, and by non-technical or procedural means. • Only the security objectives for the TOE and its IT environment are addressed by IT security requirements.

  44. Objectives : Example O.UnauthorisedVoter: Only voters eligible to vote who are unmistakeably identified and authenticated by the TOE may cast a vote. O.Proof: All data that the TOE makes available to the voter can not be used by the voter to prove his vote to third parties. O.IntegrityMessage: The TOE must verify that the content of the authentication message, identification data, ballot data, vote records and the confirmation cannot covertly be deleted, inserted, replayed or amended during transmission (between the client-side and server-side TOE).

  45. Objectives : Example O.ElectionSecrecy: The TOE guarantees election secrecy during transmission; in other words it should not be possible to match the voter to his vote in plain text form. In particular, no conclusions about the number of crosses and/or their position on the vote, or whether it is valid or spoilt, can be drawn from the number or size of the messages. O.SecretMessage: The TOE guarantees the trustworthiness of the identification data, the content of the authentication message and of the vote during transmission. Finally, this is necessary to deny the network attacker the possibility of calculating intermediate results. O.WrongServer: The client-side TOE guarantees that it is communicating with the authentic server-side TOE and vice-versa.

  46. Requirements (CC) • The IT security requirements are the refinement of the security objectives into a set of security requirements for the TOE and security requirements for the environment which, if met, will ensure that the TOE can meet its security objectives. • The CC presents security requirements under the distinct categories of functional requirements and assurance requirements.

  47. Functional Requirements • The functional requirements are levied on those functions of the TOE that are specifically in support of IT security, and define the desired security behavior. • Part 2 defines the CC functional requirements. Examples of functional requirements include requirements for identification, authentication, security audit and non-repudiation of origin.

  48. Functional Requirements : Example FDP_IFC.1 Teilweise Informationsflusskontrolle Ist hierarchisch zu: Keinen anderen Komponenten. Abhängigkeiten: FDP_IFF.1 Einfache Sicherheitsattribute FDP_IFC.1.1 Die TSF müssen die SFP for online elections für subjects {voters, election committee}, objects {vote, vote records, identification data, content of the authentication message, authentication data, ballot data, confirmation, polling data, ballot box}, monitored operations {voting process on client-side TOE, starting of the online election on the server-side TOE, rerun of the election on the TOE, blowing the final whistle on the TOE } durchsetzen.

  49. Functional Requirements : Example FDP_IFF.1 Einfache Sicherheitsattribute Ist hierarchisch zu: Keinen anderen Komponenten. Abhängigkeiten: FDP_IFC.1 Teilweise Informationsflusskontrolle FMT_MSA.3 Initialisierung statischer Attribute FDP_IFF.1.1 Die TSF müssen die SFP for online elections auf Grundlage folgender Arten von Subjekt- und Informations-Sicherheitsattributen voting right, polling period, election period and number of users authenticated as election committee durchsetzen.

  50. Functional Requirements : Example FDP_IFF.1 Einfache Sicherheitsattribute FDP_IFF.1.2 Die TSF müssen einen über eine kontrollierte Operation erfolgenden Informationsfluss zwischen dem kontrollierten Subjekt und den kontrollierten Informationen erlauben, wenn die folgenden Regeln zutreffen: The voter cannot identify and authenticate himself on the server-side TOE if the attribute election period is set to during, the attribute voting right is not set and the attribute voting process is set to null. If the identification and authentication were successful, the voting right attribute is set to valid. The voter can make his choice of candiate and initiate vote casting if the attribute election period is set to during and the attribute voting process is set to null. The election process attribute is then set to valid.

More Related