Overview

435 views

Published on

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
435
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
13
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • Prevention is ideal, because then there are no successful attacks. Detection occurs after someone violates the policy. The mechanism determines that a violation of the policy has occurred (or is underway), and reports it. The system (or system security officer) must then respond appropriately. Recovery means that the system continues to function correctly, possibly after a period during which it fails to function correctly. If the system functions correctly always, but possibly with degraded services, it is said to be intrusion tolerant. This is very difficult to do correctly; usually, recovery means that the attack is stopped, the system fixed (which may involve shutting down the system for some time, or making it unavailable to all users except the system security officers), and then the system resumes correct operations.
  • All security policies and mechanisms rest on assumptions; we’ll examine some in later chapters, most notably Chapter 22, Malicious Logic. Here is a taste of the assumptions. Policies: as these define security, they have to define security correctly for the particular site. For example, a web site has to be available, but if the security policy does not mention availability, the definition of security is inappropriate for the site. Also, a policy may not specify whether a particular state is “secure” or “non-secure.” This ambiguity causes problems. Mechanisms: as these enforce policy, they must be appropriate. For example, cryptography does not assure availability, so using cryptography in the above situation won’t work. Further, security mechanisms rely on supporting infrastructure, such as compilers, libraries, the hardware, and networks to work correctly. Ken Thompson’s modified C preprocessor (see the example on p. 615) illustrates this point very well.
  • A reachable state is one that the computer can enter. A secure state is a state defined as allowed by the security policy. The left figure shows a secure system: all reachable states are in the set of secure states. The system can never enter (reach) a non-secure state, but there are secure states that the system cannot reach. The middle figure shows a precise system: all reachable states are secure, and all secure states are reachable. Only the non-secure states are unreachable. The right figure shows a broad system. Some non-secure states are reachable. This system is also not secure.
  • Assurance is a measure of how well the system meets its requirements; more informally, how much you can trust the system to do what it is supposed to do. It does not say what the system is to do; rather, it only covers how well the system does it. Specifications arise from requirements analysis, in which the goals of the system are determined. The specification says what the system must do to meet those requirements. It is a statement of functionality, not assurance, and can be very formal (mathematical) or informal (natural language). The specification can be high-level or low-level (for example, describing what the system as a whole is to do vs. what specific modules of code are to do). The design architects the system to satisfy, or meet, the specifications. Typically, the design is layered by breaking the system into abstractions, and then refining the abstractions as you work your way down to the hardware. An analyst also must show the design matches the specification. The implementation is the actual coding of the modules and software components. These must be correct (perform as specified), and their aggregation must satisfy the design. Note the assumptions of correct compilers, hardware, etc .
  • Security does not end when the system is completed. Its operation affects security. A “secure” system can be breached by improper operation (for example, when accounts with no passwords are created). The question is how to assess the effect of operational issues on security. Cost-Benefit Analysis: this weighs the cost of protecting data and resources with the costs associated with losing the data. Among the considerations are the overlap of mechanisms’ effects (one mechanism may protect multiple services, so its cost is amortized), the non-technical aspects of the mechanism (will it be impossible to enforce), and the ease of use (if a mechanism is too cumbersome, it may cost more to retrofit a decent user interface than the benefits would warrant). Risk Analysis: what happens if the data and resources are compromised? This tells you what you need to protect and to what level. Cost-benefit analyses help determine the risk here, but there may be other metrics involved (such as customs). Laws and Customs: these constrain what you can do. Encryption used to be the biggie here, as the text indicates. How much that has changed is anybody’s guess. Customs involve non-legislated things, like the use of urine specimens to determine identity. That is legal, at least in the US in some cases; but it would never be widely accepted as an alternative to a password.
  • Organizations: the key here is that those responsible for security have the power to enforce security. Otherwise there is confusion, and the architects need not worry if the system is secure because they won’t be blamed if someone gets in. This arises when system administrators, for example, are responsible for security, but only security officers can make the rules. Preventing this problem (power without responsibility, or vice versa) is tricky and requires capable management. What’s worse is that security is not a direct financial incentive for most companies because it doesn’t bring in revenue. It merely prevents the loss of revenue obtained from other sources. People problems are by far the main source of security problems. Outsiders are attackers from without the organization; insiders are people who have authorized access to the system and, possibly, are authorized to access data and resources, but use the data or resources in unauthorized ways. It is speculated that insiders account for 80-90% of all security problems, but the studies generally do not disclose their methodology in detail, so it is hard to know how accurate they are. (Worse, there are many slightly different definitions of the term “insider,” causing the studies to measure slightly different things!) Social engineering, or lying, is quite effective, especially if the people gulled are inexperienced in security (possibly because they are new, or because they are tired).
  • The point to this slide is that each step feeds into the earlier steps. In theory, each of these should only affect the one before it, and the one after it. In practice, each affects all the ones that come before it. Feedback from operation and maintenance is critical, and often overlooked. It allows one to validate the threats and the legitimacy of the policy.
  • Overview

    1. 1. An Overview of Computer Security
    2. 2. Outline <ul><li>Components of computer security </li></ul><ul><li>Threats </li></ul><ul><li>Policies and mechanisms </li></ul><ul><li>The role of trust </li></ul><ul><li>Assurance </li></ul><ul><li>Operational Issues </li></ul><ul><li>Human Issues </li></ul>
    3. 3. Status of security in computing <ul><li>In terms of security, computing is very close to the wild west days. </li></ul><ul><li>Some computing professionals & managers do not even recognize the value of the resources they use or control. </li></ul><ul><li>In the event of a computing crime, some companies do not investigate or prosecute. </li></ul>
    4. 4. Characteristics of Computer Intrusion <ul><li>A computing system : a collection of hardware, software, data, and people that an organization uses to do computing tasks </li></ul><ul><li>Any piece of the computing system can become the target of a computing crime. </li></ul><ul><li>The weakest point is the most serious vulnerability. </li></ul><ul><li>The principles of easiest penetration </li></ul>
    5. 5. Security Breaches - Terminology <ul><li>Exposure </li></ul><ul><ul><li>a form of possible loss or harm </li></ul></ul><ul><li>Vulnerability </li></ul><ul><ul><li>a weakness in the system </li></ul></ul><ul><li>Attack </li></ul><ul><li>Threats </li></ul><ul><ul><li>Human attacks, natural disasters, errors </li></ul></ul><ul><li>Control – a protective measure </li></ul><ul><li>Assets – h/w, s/w, data </li></ul>
    6. 6. Types of Security Breaches <ul><li>Disclosure : unauthorized access to info </li></ul><ul><ul><li>Snooping </li></ul></ul><ul><li>Deception : acceptance of false data </li></ul><ul><ul><li>Modification, spoofing, repudiation of origin, denial of receipt </li></ul></ul><ul><li>Disruption : prevention of correct operation </li></ul><ul><ul><li>Modification, man-in-the-middle attack </li></ul></ul><ul><li>Usurpation : unauthorized control of some part of the system ( usurp : take by force or without right ) </li></ul><ul><ul><li>Modification, spoofing, delay, denial of service </li></ul></ul>
    7. 7. Security Components <ul><li>Confidentiality : The assets are accessible only by authorized parties. </li></ul><ul><ul><li>Keeping data and resources hidden </li></ul></ul><ul><li>Integrity : The assets are modified only by authorized parties, and only in authorized ways. </li></ul><ul><ul><li>Data integrity (integrity) </li></ul></ul><ul><ul><li>Origin integrity (authentication) </li></ul></ul><ul><li>Availability : Assets are accessible to authorized parties. </li></ul><ul><ul><li>Enabling access to data and resources </li></ul></ul>
    8. 8. Computing System Vulnerabilities <ul><li>Hardware vulnerabilities </li></ul><ul><li>Software vulnerabilities </li></ul><ul><li>Data vulnerabilities </li></ul><ul><li>Human vulnerabilities ? </li></ul>
    9. 9. Software Vulnerabilities <ul><li>Destroyed (deleted) software </li></ul><ul><li>Stolen (pirated) software </li></ul><ul><li>Altered (but still run) software </li></ul><ul><ul><li>Logic bomb </li></ul></ul><ul><ul><li>Trojan horse </li></ul></ul><ul><ul><li>Virus </li></ul></ul><ul><ul><li>Trapdoor </li></ul></ul><ul><ul><li>Information leaks </li></ul></ul>
    10. 10. Data Security <ul><li>The principle of adequate protection </li></ul><ul><li>Storage of encryption keys </li></ul><ul><li>Software versus hardware methods </li></ul>
    11. 11. Other Exposed Assets <ul><li>Storage media </li></ul><ul><li>Networks </li></ul><ul><li>Access </li></ul><ul><li>Key people </li></ul>
    12. 12. People Involved in Computer Crimes <ul><li>Amateurs </li></ul><ul><li>Crackers </li></ul><ul><li>Career Criminals </li></ul>
    13. 13. Methods of Defense <ul><li>Encryption </li></ul><ul><li>Software controls </li></ul><ul><li>Hardware controls </li></ul><ul><li>Policies </li></ul><ul><li>Physical controls </li></ul>
    14. 14. Encryption <ul><li>at the heart of all security methods </li></ul><ul><li>Confidentiality of data </li></ul><ul><li>Some protocols rely on encryption to ensure availability of resources. </li></ul><ul><li>Encryption does not solve all computer security problems. </li></ul>
    15. 15. Software controls <ul><li>Internal program controls </li></ul><ul><li>OS controls </li></ul><ul><li>Development controls </li></ul><ul><li>Software controls are usually the 1 st aspects of computer security that come to mind. </li></ul>
    16. 16. Policies and Mechanisms <ul><li>Policy says what is, and is not, allowed </li></ul><ul><ul><li>This defines “security” for the site/system/ etc . </li></ul></ul><ul><li>Mechanisms enforce policies </li></ul><ul><li>Mechanisms can be simple but effective </li></ul><ul><ul><li>Example: frequent changes of passwords </li></ul></ul><ul><li>Composition of policies </li></ul><ul><ul><li>If policies conflict, discrepancies may create security vulnerabilities </li></ul></ul><ul><li>Legal and ethical controls </li></ul><ul><ul><li>Gradually evolving and maturing </li></ul></ul>
    17. 17. Principle of Effectiveness <ul><li>Controls must be used to be effective. </li></ul><ul><ul><li>Efficient </li></ul></ul><ul><ul><ul><li>Time, memory space, human activity, … </li></ul></ul></ul><ul><ul><li>Easy to use </li></ul></ul><ul><ul><li>appropriate </li></ul></ul>
    18. 18. Overlapping Controls <ul><li>Several different controls may apply to one potential exposure. </li></ul><ul><ul><li>H/w control + S/w control + Data control </li></ul></ul>
    19. 19. Goals of Security <ul><li>Prevention </li></ul><ul><ul><li>Prevent attackers from violating security policy </li></ul></ul><ul><li>Detection </li></ul><ul><ul><li>Detect attackers’ violation of security policy </li></ul></ul><ul><li>Recovery </li></ul><ul><ul><li>Stop attack, assess and repair damage </li></ul></ul><ul><ul><li>Continue to function correctly even if attack succeeds </li></ul></ul>
    20. 20. Trust and Assumptions <ul><li>Underlie all aspects of security </li></ul><ul><li>Policies </li></ul><ul><ul><li>Unambiguously partition system states </li></ul></ul><ul><ul><li>Correctly capture security requirements </li></ul></ul><ul><li>Mechanisms </li></ul><ul><ul><li>Assumed to enforce policy </li></ul></ul><ul><ul><li>Support mechanisms work correctly </li></ul></ul>
    21. 21. Types of Mechanisms secure precise broad set of reachable states set of secure states
    22. 22. Assurance <ul><li>Specification </li></ul><ul><ul><li>Requirements analysis </li></ul></ul><ul><ul><li>Statement of desired functionality </li></ul></ul><ul><li>Design </li></ul><ul><ul><li>How system will meet specification </li></ul></ul><ul><li>Implementation </li></ul><ul><ul><li>Programs/systems that carry out design </li></ul></ul>
    23. 23. Operational Issues <ul><li>Cost-Benefit Analysis </li></ul><ul><ul><li>Is it cheaper to prevent or to recover? </li></ul></ul><ul><li>Risk Analysis </li></ul><ul><ul><li>Should we protect something? </li></ul></ul><ul><ul><li>How much should we protect this thing? </li></ul></ul><ul><li>Laws and Customs </li></ul><ul><ul><li>Are desired security measures illegal? </li></ul></ul><ul><ul><li>Will people do them? </li></ul></ul>
    24. 24. Human Issues <ul><li>Organizational Problems </li></ul><ul><ul><li>Power and responsibility </li></ul></ul><ul><ul><li>Financial benefits </li></ul></ul><ul><li>People problems </li></ul><ul><ul><li>Outsiders and insiders </li></ul></ul><ul><ul><li>Social engineering </li></ul></ul>
    25. 25. Tying Together Threats Policy Specification Design Implementation Operation
    26. 26. Key Points <ul><li>Policy defines security, and mechanisms enforce security </li></ul><ul><ul><li>Confidentiality </li></ul></ul><ul><ul><li>Integrity </li></ul></ul><ul><ul><li>Availability </li></ul></ul><ul><li>Trust and knowing assumptions </li></ul><ul><li>Importance of assurance </li></ul><ul><li>The human factor </li></ul>

    ×