Security for Software Engineers

James N. Helfrich

• Éditeur: Chapman and Hall/CRC
• Année: 2018
• ISBN:
  9780429014420
• Édition: 1
• Sujet: Computer Science
• Sous-sujet: Programming Games

• Targets software engineering students - one of the only security texts to target this audience.

• 
  
  

• Focuses on the white-hat side of the security equation rather than the black-hat side.

• 
  
  

• Includes many practical and real-world examples that easily translate into the workplace.

• 
  
  

• Covers a one-semester undergraduate course.

• 
  
  

• Describes all aspects of computer security as it pertains to the job of a software engineer and presents problems similar to that which an engineer will encounter in the industry.

Unit 1: Attack Vectors

We study attack vectors because these are the tools that black hats use to exploit a system. It is one thing to recognize that a vulnerability may exist in your code. It is another thing entirely to realize exactly what harm can result from it. The purpose of this unit is to impress upon us how serious a security vulnerability may be.

CHAPTER 2 : CLASSIFICATION OF ATTACK

The essential skill of this chapter is to recognize the many different ways an attack can be manifested. Only by understanding all of these attack vectors can we take steps to prevent them.

The first step in writing secure code is to understand how black hats exploit vulnerabilities. For this to be done, a few terms need to be defined.

Asset

An asset is something of value that a defender wishes to protect and the attacker wishes to possess. Obvious assets include credit-card numbers or passwords. Other assets include network bandwidth, processing power, or privileges. A user’s reputation can even be considered an asset.

Threat

A threat is a potential event causing the asset to devalue for the defender or come into the possession of the attacker. Common threats to an asset include transfer of ownership, destruction of the asset, disclosure, or corruption.

Vulnerability

A threat to an asset cannot come to pass unless there exists a weakness in the system protecting it. This weakness is called a vulnerability. It is the role of the software engineer to minimize vulnerabilities by creating software that is free of defects and uses the most reliable asset protection mechanisms available.

Risk

A risk is a vulnerability paired with a threat. If the means to compromise an asset exists (threat) and insufficient protection mechanisms exist to prevent this from occurring (vulnerability), then the possibility exists that an attack may happen (risk).

Attack

An attack is a risk realized. This occurs when an attacker has the knowledge, will, and means to exploit a risk. Of course not all risks result in an attack, but all attacks are the result of a risk being exploited.

Mitigation

Mitigation is the process of the defender reducing the risk of an attack. Attacks are not mitigated; instead risks are mitigated. There are two fundamental ways this can be accomplished: by reducing vulnerabilities or by devaluing assets.

An attack vector is the path an attacker follows to reach an asset. This may include more than one vulnerability or more than one asset. To see how these concepts are related, consider the following scenario: a malicious student wishes to change his physics grade on the school’s server. First we start with the asset: the grade. Next we consider the threat: damage the integrity of the grade by altering the data on the school’s server. The intent of the system is for this threat to be impossible. If a vulnerability in the system exists, then the threat is possible. This may happen if one of the administrators uses unsafe password handling procedures. Consider the case where one of the employees in the registrar’s office keeps his password written on a post-it note under his keyboard. Now we have a risk: a malicious student could obtain that password and impersonate the administrator. This leads us to the attack. Our malicious student learns of the post-it note and, when no one is looking, writes down the password. The next day he logs in as the administrator, navigates to the change-grade form, and alters the grade. Fortunately, an alert teacher notices that the failing physics grade was changed to an ‘A’. With some work, the source of the problem was identified. Mitigation of this attack vector is then to create a university policy where no passwords are to be written down by employees.

Classification of Attacks

Software engineers are concerned about attack vectors because they illustrate the types of vulnerabilities that could yield an asset being compromised. An important part of this process is classification of possible attacks. There are three axes or dimensions of this classification process: the state of the asset, the type of assurance the asset offers, and the type of vulnerability necessary for an attack to be carried out. These three axes are collectively called the McCumber Cube (McCumber, 1991).

Classification schemes are useful not only in precisely identifying a given attack that has transpired or is currently underway (an activity more in line with an I.T. professional than a software engineer), but also to brainstorm about different attack vectors that may be possible at a given point in the computing system.

Figure 02.1: McCumber Cube

Perhaps it is best to explain these attributes by example. Consider a bank attempting to prevent a thief from misusing client assets (money in this case). The thief has a wide range of options available to him when contemplating theft of the assets.

Type of Asset

The asset face of the McCumber Cube maps directly to the three security assurances. While we analyze these independently, it is important to realize that most user assets are a combination of the three.

Confidentiality

Confidentiality is the assurance that the software system will keep the user’s private data private. This could also be described as the assurance that only the owner of an asset can specify how the asset is viewed.

Attacks of confidentiality are called disclosure attacks. If an individual views an asset contrary to the wish of the owner, then a confidentiality breech or a disclosure attack has occurred.

Back to the aforementioned bank example, this will assure the client of a bank that his account balance will not be disclosed to the public. The attacker does not need to steal the client’s money to attack the money; he can simply post the client’s bank statement onto the front door of the bank.

Integrity

The assurance is that the software system will preserve the user’s data. It is a promise that the data is not destroyed, will not be corrupted accidentally, nor will it be altered maliciously. In other words, the user’s asset will remain in the same condition in which the user left it. In this digital age, it is difficult to make integrity guarantees. Instead, the best we can hope for is to detect unauthorized tampering.

Attacks on integrity are called alteration attacks. If a change has been made to the user’s data contrary to his will, then integrity has been compromised or an alteration attack has occurred.

In the banking example, there are many ways in which the attacker can launch an alteration attack. He could steal the contents of the client’s safety deposit box, he could alter the password to the client’s account, or he could deface the bank’s website. In each case, the state of one of the bank’s assets has changed in a way that was contrary to the bank’s will.

Availability

The availability assurance is that the user can have access to his informational, computational, or communication resources when he requires it. As with the integrity assurance, this includes resistance to availability problems stemming from software defects as well as denial attacks from individuals with malicious intent.

Attacks on availability are called denial attacks, also known as denial of service (D.o.S.). If an attacker is able to disrupt the normal operation of a system in such a way that the availability of system resources is impacted, then a denial attack has occurred.

In the banking example, there are many ways that an attacker can launch a denial attack. He could put sleeping gas in the ventilation system temporarily incapacitating the employees, he could get a hundred of his friends to flash-mob the bank thereby consuming all the time and attention of the clerks, or he could detonate a bomb in the building destroying everything inside. In other words, denial attacks can be inconveniences, temporary outages, or permanent outages.

Attacks on C.I.A. assurances are collectively called ...

Table des matières

• Cover
• Half Title
• Title Page
• Copyright Page
• Table of Contents
• Unit 0: Introduction to Security
• Unit 1: Attack Vectors
• Unit 2: Code Hardening
• Unit 3: Privacy
• Appendix