Third Class Secure Software Design Dr. Reem Jafar Ismail · Constructing attack profile:- An attack profile consisting of potential attacks, goals or target of attackers, techniques

Third Class

Secure Software Design

Dr. Reem Jafar Ismail

المرحلة الثالثة –امنية تصميم البرمجيات

ريم جعفر اسماعيل. د: اعداد المادة

University of Technology Secure Software Design

Computer Sciences Department

3rd

Class Lecturer: Dr. Reem Jafar Ismail

Chapter 1: Introduction to Software Security

1.1 Introduction

“What is security?” Security means different things to different people. It might even mean different things to the same person, depending on the context. Software security breaches are now very extremely common and a larger percentage is caused by software design defects. Since individuals and organizations now completely depend on software systems for their day-to-day operations, it is then important to produce secure software products. Software security is concerned with protection of software and its resources. A security risk is the probability of sustaining a loss of a specific magnitude during a specific time period due to a failure of security system.

1.2 Software Security Goals

The three security goals of computer system are Confidentiality, Integrity and Availability. These goals are commonly referred as the CIA of computer security and these goals also apply to computer systems.

a. Confidentiality:- This has to do with the prevention of unauthorized disclosure of software resources such as codes, data, documents, files, GUI, and so on. b. Integrity:- This is prevention of unauthorized modification of software resources. c. Availability:- This is concerned with the unauthorized denial of the services of software resources. Over the years, there have been several security mechanisms to achieve these goals. Some of these mechanisms are authentication and authorization, access control, encryption, and so on, but the rate and magnitude of attacks on computer system is increasingly alarming. Some of the interests of attacker are financial and knowledge gains, malicious intention, competitive edge and so on. The situation is even worse now that we have mobile codes in distributed network and exposure to Internet.

1.3 Problems of Producing Secure Software

Producing secure software is complex and requires high integration of security and software engineering. So the problems of producing secure software are as follows:-

1



3rd


a. Attackers’ Knowledge:- As software security continue to gain the attention of security experts and organizations, the tools and techniques used by attackers are becoming increasingly sophisticated and invasive. b. Complexity of software:- Software development is a complex process because it involves many activities and specialties. It involves different units, stages and personalities, and all these have to be integrated to achieve successful software production. The situation is even worse with the connection to Internet and the use of mobile codes. c. Security Education:- Producing secure software requires a lot of security training, education and experience. Many software developers are not well grounded in computer security. To what extent of the techniques and tools of attackers do they understand? Also, many programming books do not teach how to write secure programs. Many curricular of schools offering computer science do not properly address computer security. d. Attitude of Software Engineers:- In the past, software developers were only interested in producing software product with the desired quality. Little attention was paid on making secure products. But, the situation is changing now that everybody is aware of the implications of vulnerabilities in software. e. Inadequacy of Computer Security Models:- Many security models are still not adequate for producing secure software products. Implementing some of them is complex and difficult to realize. 1.4 Overview of Software Development Stages

It has been said that producing software requires integrating Software Engineering (SE) process with Security Engineering. In doing this, a careful understanding of software development process is important. We now present an overview of software development process. The summary of stages of software development is:

a. Requirement definition Fact findings

Investigating the current system

Modeling the current system

Logical models of the required system Result: Requirement specification

b. Design Structuring and partitioning of the design into software sub-components

Detailed design of the components

Formation of the system structure and relationships

Result: Design document containing system abstraction and their relationships 2



3rd


c. Coding Programming components of the system

Unit testing

Result: Tested software subcomponents

d. System testing Integrating subcomponents together

Integration testing

System testing to ensure that the system meets its requirements Result: Software product

e. Implementation and Maintenance Installing the system in `live` environment

Training the users

Maintenance

Implementing enhancements as demanded by changes in the environment and users

Result: Working software product

3



3rd


1.5 Secure Software Development Model (SSDM)

SSDM is a model that integrates security engineering with software development process. As shown in Figure 1, it is a unified model that combines some existing software security techniques. It is structured towards creating secure software products. The dotted lines in Figure 1, shows continuous links along an engineering path. The model shows clearly how software development should be linked to security engineering in order to produce secure software products.

4



3rd


Figure 1: Secure Software Development Model (SSDM)

5



3rd


1.6 SSDM Security Engineering Process

As shown in Figure 1, the security engineering path is divided into five stages. a. Security Training

Not all software engineers have adequate knowledge of computer security. The essence of security training is to provide adequate security education to stakeholders in software development.

The key training requirements are: Security awareness:- This involves educating software engineers on

general security concepts. Cases on previous security breaches and their consequences should be presented to them in order to appreciate the need for adequate protection of software products.

Knowledge of attackers on previous related applications:- Software engineers should be educated on nature of previous attacks. There is need to understand attackers’ techniques and tools and implications so as to properly understand attackers’ behaviours. There is also need to understand penetration techniques of actions like logic bombs, trojans, virus, worms, and so on.

Understanding attackers’ interests on software being developed:-Software developers

must be able to study a software system and identify software resources that might be of interest to potential attackers. This is important so as to develop techniques for protecting these resources.

Knowledge about secure development practices:- Software developers should also be educated on previous practices on secure software development and their strengths and weaknesses so as to move secure software development forward.

b. Threat Modeling

A threat model is used to effectively and comprehensively identify attackers and their capabilities. Every software development that must be secure must have it own threat model because the common security criteria might not be suitable for all software products. SSDM threat model is divided into three parts.

i. Understand the nature of the software This requires understanding:

The type of the software:- The type of a software system determines the magnitude

and nature of resources on the software system.

Complexity of the software:- Provision of adequate security to big and complex system is a huge challenge. Complex software systems need

6



3rd


more comprehensive threat analysis and modeling in order to capture potential attacks effectively.

Other associating software:- The type and complexity of other software

systems that are handshaking with the software under consideration must be investigated. The level of security of the associating software must be ascertained.

ii. Identify attackers/threats The major issues here are:

Assessing the operating environment:- There is need to study the

environment in which the software must operate in order to identify the possible potential attackers and their categories.

Identifying the goals/targets of different category:- Based on previous experience, we must be able to identify the possible interests and goals of attackers in the software.

Identifying techniques and tools used by attackers:- It is also important to know the possible techniques and tools to be used by these attackers in order to develop techniques to block them.

Identifying possible future patterns/behaviours of attackers:- Ensuring that software product are secured is not to think about the present situation alone, but to continue to plan ahead because of the changing nature of attackers’ techniques and tools. There is need to identify future behaviours of attackers and undertake some measures to prevent them.

Constructing attack profile:- An attack profile consisting of potential attacks, goals or target of attackers, techniques and tools of attackers and future behaviours of attackers, should be constructed.

iii. Identify possible vulnerabilities

Based on the information on the previous attacks, all likely vulnerabilities that may be introduced into the system must be identified. This will enable the software engineers not to carry out the design in a way that the vulnerabilities would be avoided.

c. Security Specification (SS)

This entails stating the guidelines and procedures that guarantee security of the system The SS should contain the following:-

i. Security needs:- This involves stating list of attacks to guide against and construction of vulnerability profile ii. State security policies:- This involves a clear definition of how to guide against attacks. Some specific issues to be included are: Avoiding errors through out the development

Correct all errors at the time of first notice

7



3rd


Employing programming tactics that prevent vulnerabilities

Employing module integration method that guarantee security

iii. How to coordinate security implementation iv. How to make the system to adapt to the changing landscape of security

v. How to monitor security postures of the software system

d. Review SS

This is to check whether the design content of the software is in accordance with the SS. This is important because if the design is defective, then the software design must incorporate the security specifications. If the design has not guaranteed the items in the SS, then the design will be reviewed.

e. Penetration Testing

Capabilities of the software in preventing attacks are tested here. It is important so as to: Test the security of the software and its resources

Determine if the current security posture of the software is actually detecting and preventing attacks.

Penetration testing is carried out in a way that all identified attacks and future attack patterns are initiated on-line into the software, and the capability of the software in preventing these attacks is monitored.

8



3rd


1.7 Software Project Goals

Key software project goals include:

Functionality This is the number one driver in most software projects, which are obsessed with meeting functional requirements. And for good reason too. Software is a tool meant to solve a problem. Solving the problem invariably involves getting something done in a particular way.

Usability People like programs to be easy to use, especially when it comes to conducting electronic commerce. Usability is very important, because without it software becomes too much of a hassle to actually work with. Usability affects reliability too, since human error often leads to software failure.

The problem is, security mechanisms, including most uses of cryptography, elaborate login procedures, tedious audit requirements, and so on, often cause usability to plummet. Security concerns regularly impact convenience too. Security people often deride cookies, but cookies are a great user-friendly programming tool!

Efficiency People tend to want to squeeze every ounce out of their software (even when efficiency isn’t needed). Efficiency can be an important goal, though it usually trades off against simplicity. Security often comes with significant overhead. Waiting around while a remote server somewhere authenticates you is no fun. But it can be necessary.

Time to market “Internet time” happens. Sometimes the very survival of an enterprise requires getting mind share fast in a quickly evolving area. Unfortunately, the first thing to go in a software project with severe time constraints is any attention to software risk management. Design, analysis, and testing corners are cut with regularity. This often introduces grave security risks.

Fortunately, building secure software does not have to be slow. Given the right level of expertise, a secure system can sometimes be designed more quickly than an ad hoc cousin system with little or no security.

Simplicity The good thing about simplicity is that it is a good idea for both software project and security. Everyone agrees that keeping it simple is good advice.

9



3rd


1.8 The Notion of Software Security

Here is a look on some of the definitions of software security:

“Software Security is the ability of the software to resist, tolerate, and recover from events that intentionally threaten its dependability”

“Software Security is about building secure software: designing software to be secure, making sure that software is secure, and educating software developers, architects, and users about how to build secure things”

“The idea of engineering software that continues to function correctly

under malicious attack” “The process of designing, building, and testing software for security”

“Defends against software exploit by building software to be secure in

the first place, mostly be getting the design right (which is hard) and avoiding common mistakes (which is easy)"

“Software Security is system-wide issue that takes into account both

security mechanisms (such as access control) and design for security (such as robust design that make software attacks difficult”

There is not even one standard definition of software security. Different people have defined security in different terms. The important thing to notice in the above definitions is that most of them talk about ‘building secure software’, instead of ‘securing software’. Building secure software actually means to design and implement secure software while securing software aims to first build the software and then secure it. The concept of software security will be explained in more detail later in this chapter.

1.9 Software Security Vs Application Security

Application security can be defined as:

“Application security is about protecting software and the system that software runs in a post-facto way, after development is complete”

There is a considerable difference between the idea of software security and application security. As mentioned earlier, software security is about building/engineering secure software by planting security into the development lifecycle. It involves incorporating security into every phase of the development life cycle and educating stakeholders about the notion of security. On the other hand application security also means securing software after the development is completed, i.e. the securing software in a post facto way. In addition it also follows approaches such as penetrate and patch, and input filtering. Application security tends to secure software from known and exploited vulnerabilities. It

10



3rd


does nothing towards building secure software. It is hard to secure defected software than defect-free software, for example, software having buffer overflow vulnerabilities can be protected by input filtering but a better technique would be to have software without buffer overflow vulnerabilities. Therefore in comparison with application security, it can be said that software security is a better solution than application security towards securing software.

1.10 Software Security Vs Information Security

Information Security can be defined as:

“The concepts, techniques, technical measures, and administrative measures used to protect information assets from deliberate or inadvertent unauthorized acquisition, damage, disclosure, manipulation, modification, loss, or use”

To understand the difference between software security and information security, it is important to understand the difference between inherent nature of information and software. Information is something that is passive in nature. Information can be harmful if stolen, deleted or modified. Software on the other hand is active in nature. It can be harmful both actively and passively. Software can be stolen for misuse and can be exploited during execution. Securing information requires avoiding unauthorized access to the system where information is stored. Information security has nothing to do with the way information was created while software security depends a lot on how the software is created. In short information security is about protecting information from unauthorized access while software security is about building secure software.

11



3rd


1.11 Hackers, Crackers, and Attackers

We’ll admit it; we are hackers. But don’t break out the handcuffs yet; we don’t run around breaking into machines, reading other people’s e-mail, and erasing hard disks. In fact, we stay firmly on this side of the law (well, we would in a world where driving really fast is always legal).

The term “hacker” originally had a positive meaning. It sprang from the computer science culture at MIT in the late 1960’s, where it was used as a badge of honor to refer to people who were exceptionally good at solving tricky problems through programming, often as if by magic. For most people in the

Unix development community, the term’s preferred definition retains that meaning, or is just used to refer to someone who is an excellent and enthusiastic programmer. Often, hackers like to tinker with things, and figure out how they work.

Software engineers commonly use the term “hacker” in a way that carries a slightly negative connotation. To them, a “hacker” is still the programming world’s equivalent of MacGyver; someone who can solve hard programming problems if given only a ball of fishing twine, a matchbook and two sticks of chewing gum. The problem for software engineers is not that “hackers” (by their definition) are malicious; it is that they believe cobbling together an ad hoc solution is at best barely acceptable. They feel careful thought should be given to software design before coding begins. They therefore feel that hackers are developers who tend to “wing it”, instead of using sound engineering principles. (Of course, we never do that! Wait, did we say that we’re hackers?)

Far more negative is the definition of “hacker” normal people use (including the press). To most people, a hacker is someone who maliciously tries to break software. If someone breaks onto your machine, many people would call that person a “hacker”. Needless to say, this definition is one that the many programmers who consider themselves “hackers” resent.

Do we call locksmiths burglars just because they could break into our house if they wanted to do so? Of course not. But that’s not to say that no locksmiths can be burglars.

And, of course, there are hackers who are malicious, and do break into other people’s machines, and do erase disk drives. These people are a very small minority compared to the number of expert programmers who consider themselves “hackers”.

In the mid 80’s, people who considered themselves “hackers”, but hated the negative connotations the term carried in most peoples’ minds (mainly due to media coverage of security problems), coined the term “cracker”. A “cracker” is someone who breaks software for nefarious ends.

Unfortunately, this term hasn’t caught on much outside of hacker circles. The media doesn’t use it, probably because it is already quite comfortable with

12



3rd


“hacker”. And it sure didn’t help that they called the movie “Hackers” instead of “Crackers”. Nonetheless, we think it is insulting to lump all hackers together under a negative light. But we don’t like the term “cracker” either. To us, it sounds dorky, bringing images of saltines to mind. So when we use the term

“hacker”, that should give you warm fuzzy feelings. When we use the term “malicious hacker”, “attacker” or “bad guy”, it is okay to scowl. If we say “malicious hacker”, we’re generally implying that the person at hand is skilled.

If we say anything else, they may or may not be.

13



3rd


Chapter 2: Selecting Technologies

2.1 Choosing a Language

The single most important technology choice most software projects face is

which programming language (or set of languages) to use for implementation.

There are large number of factors that impact this choice. For example,

efficiency is often a requirement, leading many projects to choose C and C++ as

an implementation language.

Reliability is another factor that impact secure project, the more error checking

a language can do the more reliable the programs written in that language. For

that reason, Java has a distinct advantage because it has a much stronger static

type system. Similarly, Java offers advantages over dynamic languages in which

type errors and other mistakes only become apparent during runtime.

One of the biggest mistakes companies make in choosing a language is the

failure to consider the impact on software security. However, many people

either choose to ignore it completely or seem to assume that all languages are

created equal when it comes to security. Unfortunately, this is not the case.

2.2 Choosing an Operating System

Modern operating systems are logically divided into a system kernel and user-

level code (often called user space). Programs run in user space need to call

down into the kernel when special services are needed.

Many critical services are run in kernel space. The kernel usually has some sort

of security model that manage access to devices, files, processes, and objects.

The underlying mechanism and the interface to that mechanism tend to be

significantly different, depending on the operating system.

For programs running in user space, there are common security systems. One of

the most important is process space protection. In a good operating system, a

single process is not allowed to access any of the memory allocated to other

processes directly. Additionally, no process can directly access the memory

currently marked as “in use” by the operating system. In this way, interprocess

communication is mediated by the operating system. Windows NT/2000 and all

UNIX systems afford this kind of protection.

14



3rd


Windows 95/98/Me family of operating systems was not originally designed to

afford the kind of protection modern operating systems provide. Operating

systems like DOS were designed in a time when security was not a significant

issue because most PCs were single-user devices.

2.3 Authentication Technologies

Choosing a reasonable authentication technology is important. Password

authentication approach is unfortunately not the only kind of authentication that

is frequently weak. There are many types of authentication mechanism, and

each is difficult to get right.

1.Host-Based Authentication

A common way to authenticate network connection is to use the Internet

Protocol (IP) address attached to the connection. This technique is popular with

firewall products, for example. Sometimes, people will instead authenticated

against a set of DNS (Domain Name Service) names, and thus will do a lookup

on the IP address before authenticating. Both of these techniques are easy to

implement because the information on how to do so is readily available. Similar

authentication techniques use MAC (Medium Access Control) address of the

remote host’s network card, or any sort of unique identification (ID) associated

with that machine.

2. Physical Tokens

One common technique for authentication is to use physical tokens, such as a

key, a credit card, or a smart card. Without the physical tokens, authentication

should not be possible. This sort of authentication is widespread, but has a

number of associated problems.

In the context of computer systems, one problem with physical tokens is that some sort input device is necessary for every client of the system.

Physical tokens suffer from several problems:

In the case of credit cards letting the user type in the credit card number solves the problem, but this solution suffers in that it doesn’t really

15



3rd


guarantee that the person in the credit card number is actually in possession of the card (means invalid user).

Another problem with physical tokens is that they can be lost or stolen(means invalid user).

Many physical tokens can be duplicated easily by clone. The attacker which has a good skill can model the key.

3. Biometric Authentication

Biometric authentication is the measuring of physical or behavioral

characteristics of a human and using these characteristics as a metric for

authentication. There are a number of different types of biometric authentication

that are used in real world systems. Physical characteristics that can be

measured include fingerprint, features of the eye, and facial features.

Example of behavioral biometrics includes handwritten signatures and

voiceprint. In the real world, we validate signature by sight, even though a

skilled attacker can reliably forge a signature that most people cannot dis-act of

signing (pen speed, pressure, and so on) in some digital format, then it would be

far more difficult to forget a real signature.

4. Cryptographic Authentication

Cryptographic authentication uses mathematics and a digital secret to

authenticate users. This type of authentication can be seen as a digital analog to

having physical token.

16



3rd


Chapter 3: The Ten Best Practices

for Secure Software Development

Best Practice #1: Protect the Brand Your Customers Trust

Best Practice #2: Know Your Business and Support it with Secure Solutions

Most skilled security professionals agree that, along with a strong background in technology, a thorough understanding of the business is of paramount importance when it comes to creating secure solutions for that business. Though some purist security technologists may find it difficult to accept, it is nevertheless true that security is there for the business and not the other way around. Security exists to enable the business, not to be an impediment. The answer to the question, “Why were brakes invented?” could be answered in two ways: to prevent the vehicle from an accident, or to allow the vehicle to go faster. Security is similar; it can prevent the business from a crash, or allow the business to go faster.

Best Practice #3: Understand the Technology of the Software

Not only is it critical to know the business, but one must have a strong background in technology to be effective in building or buying secure software. A lack of understanding of the technology used to build or buy software can lead to insecure implementations of the software.

When it comes to building the software in-house, a thorough understanding of

the existing infrastructural components, such as network segregation, hardened

hosts, and public key infrastructure, is necessary to ensure that the deployment

of the software will, first, be operationally functional and, second, not weaken

the security of the existing environment. In other words, understanding the

interplay of your current technological components with the software you build

and/or deploy will help determine the impact on overall security. Further,

understanding the technology used in building software can help towards

making decisions that favor security.

Best Practice #4: Ensure Compliance to Governance, Regulations, and Privacy In this day and age, an industry that is not regulated is more the exception than the norm as opposed to just a few years ago when the industry that was

17



3rd


regulated was the exception. The increase in regulatory and privacy

requirements imposes a serious burden on organizations. Governance, Risk, and

Compliance (GRC) is not just an industry buzz phrase, but a reality and a means

toward meeting regulatory and privacy requirements.

Best Practice #5: Know the Basic Tenets of Software Security

When it comes to secure software, there are some tenets with which the SSLP

must be familiar. These basic tenets are: protection from disclosure

(confidentiality); protection from alteration (integrity); protection from

destruction (availability); who is making the request (authentication); what

rights and privileges does the requestor have (authorization); the ability to build

historical evidence (auditing); and the management of configuration, sessions,

and exceptions. Knowledge of these basic tenets, and how they can be

implemented in software, is of vital importance for the SSLP.

Best Practice #6: Ensure the Protection of Sensitive Information

In addition to ensuring that the brand your customers trust is protected, it is essential that any sensitive information be protected as well. Sensitive information refers to any information upon which the organization places a measurable value. By implication, this is information that is not in the public domain and would result in loss, damage, or even business collapse should the information be lost, stolen, corrupted, or in any way compromised. Sensitive information may be personal, health, financial, or any other information that can affect the competitive edge of your organization.

While it is easy to identify the sensitivity of certain data elements such as,

health records or credit card information, other elements may not be that

evident. Determination of what is sensitive and what is not can be accomplished

by undertaking a data classification exercise, with the business stakeholders

involved in this process. Software that either transports, processes, or stores

sensitive information must build in necessary security controls to protect this

information.

Best Practice #7: Design Software with Secure Features

Best Practice #8: Develop Software with Secure Features

Designing for security in software is futile unless you plan to act on the design

and incorporate necessary secure controls during the development stage of your

software development lifecycle. It is imperative that secure features are not

18



3rd


ignored when design artifacts are converted into syntax constructs that a

compiler or interpreter can understand. Writing secure code is no different than

writing code that is usable, reliable, or scalable.

Best Practice #9: Deploy Software with Secure Features. Best Practice #10: Educate Yourself and Others on How to Build Secure Software.

19



3rd


Chapter 4: Open Source and Closed Source

4.1 Open Source and Closed Source:

Closed Source:

Under the closed source model source code is not released to the public. Closed

source software is maintained by a team who produces their product in a

compiled executable state, which is what the market is allowed access to.

Microsoft, the owner and developer of Windows and Microsoft Office, along

with other major software companies, have long been proponents of this

business model. Although in August 2010, Microsoft interoperability general

manager Jean Paoli said Microsoft "loves open source" and its anti-open source

position was a mistake.

Open Source:

Open source software refers to applications developed in which the user can access and alter the "source" code itself. Some open source applications have restrictions on their use and distribution, but many do not. Unlike public domain software, Open source software does have copyrights. Examples of open source software include: LINUX, Apache, Firefox, KOffice, Thunderbird, OpenOffice, and SquirrelMail.

Open source doesn't just mean access to the source code. The distribution terms of open-source software must comply with the following criteria:

1. Free Redistribution

The license shall not restrict any party from selling or giving away the software as a component of an aggregate software distribution containing programs from several different sources. The license shall not require a royalty or other fee for such sale.

2. Source Code

The program must include source code, and must allow distribution in source code as well as compiled form. Where some form of a product is not distributed with source code, there must be a well-publicized means of obtaining the source code for no more than a reasonable reproduction cost preferably, downloading via the Internet without charge. The source code must be the preferred form in which a programmer would modify the program. Deliberately obfuscated source

20



3rd


code is not allowed. Intermediate forms such as the output of a preprocessor or translator are not allowed.

3. Derived Works

The license must allow modifications and derived works, and must allow them to be distributed under the same terms as the license of the original software.

4. Integrity of the Author's Source Code

The license may restrict source-code from being distributed in modified form only if the license allows the distribution of "patch files" with the source code for the purpose of modifying the program at build time. The license must explicitly permit distribution of software built from modified source code. The license may require derived works to carry a different name or version number from the original software.

5. No Discrimination Against Persons or Groups

The license must not discriminate against any person or group of persons.

6. No Discrimination Against Fields of Endeavor

The license must not restrict anyone from making use of the program in a specific field of endeavor. For example, it may not restrict the program from being used in a business, or from being used for genetic research.

7. Distribution of License

The rights attached to the program must apply to all to whom the program is redistributed without the need for execution of an additional license by those parties.

8. License Must Not Be Specific to a Product

The rights attached to the program must not depend on the program's being part of a particular software distribution. If the program is extracted from that distribution and used or distributed within the terms of the program's license, all parties to whom the program is redistributed should have the same rights as those that are granted in conjunction with the original software distribution.

21



3rd


9. License Must Not Restrict Other Software

The license must not place restrictions on other software that is distributed along

with the licensed software. For example, the license must not insist that all other

programs distributed on the same medium must be open-source software.

10. License Must Be Technology-Neutral

No provision of the license may be predicated on any individual technology or style of interface.

4.2 Code Obfuscation:

Code obfuscation is to transform the code in such a way that it becomes more

difficult for the attackers to read and understand. One common form of

obfuscation is to rename all the variables in your code to arbitrary names. This

obfuscation is not very effective though, so there are several simple techniques

that can make the code more difficult to comprehend:

1. Add code that never executes, or that does nothing. if you add code that

never executes, you need to keep it from being obvious that is never executes.

One thing to do is to take calculations and make them far more complex than

they need to be. Another thing to do is to use mathematical identities or other

special information to construct conditions to loop conditions that always

evaluate to either true or false. The idea is that a person or program

deobfuscation your code will not be able to figure out that the condition should

always evaluate the same way.

2. Move code around. Spread related functions as far apart as possible. Copy

and rename the same functions, instead of calling it from multiple places.

Combine multiple functions into single function that has some extra logic to

make sure it calls the right block of code depending on how it got called. If an

algorithm specifies that you do some operation A and then do B, move B as far

from A as possible by putting other, unrelated tasks in between.

3. Encode your data oddly. Picking strings directly out of memory is easy if

you don’t take efforts to stop it. Convert everything to a strange character set,

and only make string printable when necessary. Or, encrypt all you data in

memory, using a set of keys that are spread throughout your program.

22



3rd


4.3 When Security Problem is Discovered in Open Source:

Open source software has the potential to be more secure than closed. When a

security problem is identified, your user community is best served if you notify

them as soon as repaired version is available. One good way is to have an e-mail

distribution list for the sole purpose of announcing security bugs. You should

also put a prominent notice in your software, with easy instructions, such as the

following:

SCURITY NOTICE: This program currently contains no known security

problems. If a security problem that could affect you is found, we’d like to tell

you about it. If you’d like to receive notification if such situation does occur,

send an e-mail to [email protected]. We will not use your

e-mail address for any other purpose than to notify you of important security

information.

The open source software creators could also keep original software in a

popular web site, so that when a user crashes its software he can download

another original copy of the software to use it.

23



3rd


Chapter 5: Buffer Overflows

5.1 Buffer Overflows:

Buffer overflows begins with something every program needs, someplace to put

stuff. Most useful computer programs create sections in memory for

information storage, when continuous chunks of the same data type are

allocated, the memory region is known as a buffer. The C programming

language allows programmers to create storage at runtime in two different

sections of memory: the stack and the heap.

C programmers must take care when writing to buffers that they do not try to

store more data in the buffer than it can hold. Just as a glass can only hold so

much water, a buffer can hold only so many bits. If you put too much water in a

glass, the extra water has to go somewhere. Similarly, if you try to put more

data in a buffer than fit, the extra data have to go somewhere, and you may not

always like where it goes. What happens is that the next continues chunk of

memory is overwritten. When a program writes past the bounds of buffer, this is

called buffer overflow.

5.2 Buffer Overflows is a Security Problem:

When a buffer overflow happen, the excess data may trample other

meaningful data that the program may wish to access in the future. Sometimes

changing these other data can lead to a security problem.

In the simplest case, consider a Boolean flag allocated in memory directly after

the buffer. Say that the flag determines whether the user running the program

can access private files. If a malicious user can overwrite the buffer, then the

value of the flag can be changed, thus providing the attacker with illegal access

to private files.

5.3 Defending Against Buffer Overflows:

Protecting the code through defensive programming is the key to avoiding

buffer overflows. The C standard library contains a number of calls that are

highly susceptible to buffer overflows that should be avoided.

24



3rd


For example, string operations are the worst case that cause buffer overflows.

Never use gets() function, this function reads a line of text from the standard

input and does not stop reading text until it sees an end-of-file character or a

newline character. So gets() function perform no bounds checking at all. It is

always possible to overflow any buffer using gets(). As alternative, use the

method fgets(). It can do the same thing gets() does, but it accepts a size

parameter to limit the number of character read in, thus giving you a way to

prevent buffer overflows. For example, instead of the following code:

void main( ) {

char buf[1024];

gets (buf);

}

Use the following

#define BUFSIZE 1024

void main( ) {

char buf[BUFSIZE];

fgets (buf, BUFSIZE, stdin);

}

Other standard functions like strcpy() copies a source string into a buffer. No

specific number of characters are copied. The number of characters copied

depends directly on how many characters are in the source string. If the source

string happens to come from user input, and you don’t explicitly restrict its size,

you could be in big trouble! If you know the size of the destination buffer, you

can add an explicit check:

If (strcpy(src) >= dest_size) {

/* Do something such as an error */

}

25



3rd


else {

strcpy(dst, src);

}

Of course, it is possible to use strcpy() without any potential problem for security problems, as can be seen in the following example:

strcpy(buf, “Hello!”);

It’s too bad that C and C++ don’t do bound checking automatically, but there is

a good reason why they don’t. The price of bond checking is efficiency. In

general, C favors efficiency in most tradeoffs.

5.4 Stack Overflows:

The classic incarnation of a buffer overflow is known as “smashing the stack.”

In a compiled program, the stack is used to hold control information, such as arguments, where the application needs to return to once it is done with the function and because of the small number of registers available on x86 processors, quite often registers get stored temporarily on the stack. Unfortunately, variables that are locally allocated are also stored on the stack. These stack variables are sometimes inaccurately referred to as statically allocated, as opposed to being dynamically allocated heap memory. If you hear someone talking about a static buffer overflow, what they really mean is a stack buffer overflow. The root of the problem is that if the application writes beyond the bounds of an array allocated on the stack, the attacker gets to specify control information. And this is critical to success; the attacker wants to modify control data to values of his bidding.

For example,

#include <stdio.h> void DontDoThis(char* input) { char buf[16];

26



3rd


strcpy(buf, input); printf("%s\n", buf); }

int main(int argc, char* argv[]) {

// So we're not checking arguments // What do you expect from an app that uses strcpy? DontDoThis(argv[1]); return 0; } Now let’s compile the application and take a look at what happens. For this demonstration, the author used a release build with debugging symbols enabled and stack checking disabled. A good compiler will also want to inline a function as small as DontDoThis, especially if it is only called once, so he also disabled optimizations. Here’s what the stack looks like on his system immediately prior to calling strcpy:

0x0012FEC0 c8 fe 12 00 Èþ.. <- address of the buf argument 0x0012FEC4 c4 18 32 00 Ä.2. <- address of the input argument 0x0012FEC8 d0 fe 12 00 Ðþ.. <- start of buf

0x0012FECC 04 80 40 00 .[] @. 0x0012FED0 e7 02 3f 4f ç.?O 0x0012FED4 66 00 00 00 f... <- end of buf

0x0012FED8 e4 fe 12 00 äþ.. <- contents of EBP register 0x0012FEDC 3f 10 40 00 ?.@. <- return address

0x0012FEE0 c4 18 32 00 Ä.2. <- address of argument to DontDoThis 0x0012FEE4 c0 ff 12 00 Àÿ.. 0x0012FEE8 10 13 40 00 ..@. <- address main() will return to

Remember that all of the values on the stack are backward. This example is from a 32-bit Intel system, which is “little-endian.” This means the least significant byte of a value comes first, so if you see a return address in memory as “3f104000,” it’s really address 0x0040103f.

Now let’s look at what happens when buf is overwritten. The first control information on the stack is the contents of the Extended Base Pointer (EBP) register. EBP contains the frame pointer, and if an off-by-one overflow happens, EBP will be truncated. If the attacker can control the memory at 0x0012fe00 (the off-by-one zeros out the last byte), the program jumps to that location and executes attacker-supplied code.

If the overflow isn’t constrained to one byte, the next item to go is the return address. If the attacker can control this value and is able to place enough assembly into a buffer that he knows the location of, you’re looking at a classic

27



3rd


exploitable buffer overflow. Note that the assembly code (often known as shell code because the most common exploit is to invoke a command shell) doesn’t have to be placed into the buffer that’s being overwritten.

It’s the classic case, but in general, the arbitrary code that the attacker has placed into your program could be located elsewhere. Don’t take any comfort from thinking that the overflow is confined to a small area.

Once the return address has been overwritten, the attacker gets to play with the arguments of the exploitable function. If the program writes to any of these arguments before returning, it represents an opportunity for additional mayhem. This point becomes important when considering the effectiveness of stack tampering countermeasures such as Crispin Cowan’s Stackguard, IBM’s ProPolice, and Microsoft’s /GS compiler flag.

As you can see, we’ve just given the attacker at least three ways to take control of our application, and this is only in a very simple function. If a C++ class with virtual functions is declared on the stack, then the virtual function pointer table will be available, and this can easily lead to exploits. If one of the arguments to the function happens to be a function pointer, which is quite common in any windowing system (for example, the X Window System or Microsoft Windows), then overwriting the function pointer prior to use is an obvious way to divert control of the application.

28



3rd


Chapter 6: Random Numbers

6.1 Random Numbers:

Random numbers are important in security for generating cryptographic keys,

shuffling cards, and many other things. Many developers assume that random()

and similar functions produce unpredictable results. Unfortunately, this is a

flawed assumption. A call to random() is really a call to traditional “pseudo-

random” number generator (PRNG) that happen to be quite predictable.

6.2 Pseudo-random Number Generator (PRNG):

Computers are completely deterministic machines. Therefore, computers can’t

be good at creating data that are truly random. How would a computer create a

random number without somehow computing it? The answer is, of course, that

it can’t. If an attacker can record everything a machine does, then there can be

no secrets. If the attacker knows the algorithm, and can reproduce the execution

of the algorithm along with its input, then there can be no secrets. Because

computers intrinsically cannot produce what people would call “real” random

numbers, they must compute them with an algorithm. Such algorithms are

called pseudo-random number generator (PRNG).

PRNGs accept inputs used to compute random numbers. If these inputs can be

known or guessed by an attacker, then the attacker can simulate the stream of

random numbers. Therefore, it is important that the inputs or outputs to our

PRNGs are themselves unable to be guessed. These inputs are called seed.

Seeds are important because they afford predictability when necessary.

Obviously, we would prefer that our seed data not be created by call to a PRNG.

Instead, we wish to somehow collect “real” randomness. As a result,

cryptographers talk about “collecting entropy”. Entropy is a measure of how

much “real” randomness in a piece of data.

Note that cryptographic PRNGs are essentially synonymous with stream ciphers

(a form of symmetric cipher). Stream cipher produce a series of pseudo-random

data, given some starting state (the key), which is XOR-ed with the plaintext to

yield cipher text.

29



3rd


6.3 Determining What Kind of Random Numbers to Use

The Problem: Your application has a need for random numbers. You must figure out what you need to do to get adequate randomness as cheaply as possible, yet still meet your security properties. To do that, you need to understand what kinds of options are available to you and what the trade-offs are. The Solution: There are essentially three classes of solutions:

Insecure random number generators

More properly, these are non cryptographic pseudo-random number generators. You should generally assume that an attacker could predict the output of such a generator.

Cryptographic pseudo-random number generators (PRNGs)

These take a single secure seed and produce as many unguessable random numbers from that seed as necessary. Such a solution should be secure for most uses as long as a few reasonable conditions are met (the most important being that they are securely seeded).

Entropy harvesters

These are sometimes "true" random number generators—although they really just try to gather entropy from other sources and present it directly. They are expected to be secure under most circumstances, but are generally incredibly slow to produce data.

For general-purpose use, the second solution is excellent. Typically, you will need entropy (i.e., truly random data) to seed a cryptographic pseudo-random number generator and will not need it otherwise, except in a few specific circumstances, such as when generating long-term keys.

You should generally avoid the first solution, as the second is worthwhile even when security is not an issue (particularly because we've seen numerous systems where people assumed that the security of their random numbers wasn't an issue when it actually turned out to be).

Entropy is highly useful in several situations. First, there's the case of seeding a random number generator, where it is critical. Second, any time where you would like information-theoretic levels of security (i.e., absolutely provable secrecy, such as is theoretically possible with a one-time pad), then cryptographic randomness will not do. Third, there are situations where a PRNG cannot provide the security level required by a system. For example, if you want to use 256-bit keys throughout your system, you will need to have 256 bits of entropy on hand to make it a full strength system. If you try to leverage an OS-level PRNG (e.g., /dev/random on Unix systems), you will not get the

30



3rd


desired security level, because such generators currently never produce data with more than 160 bits of security (many have a 128-bit ceiling).

In addition, a combination of the second and third class of solution is often a good practical compromise. For example, you might want to use entropy if it is available, but if it is not, fall back on a cryptographic solution. Alternatively, you might want to use a cryptographic solution that occasionally gets its seed changed to minimize the chance of a compromise of the internal state of the generator.

Note that cryptographic pseudo-random number generators always produce an identical stream of output when identically seeded. If you wish to repeat a stream of numbers, you should avoid reseeding the generator (or you need to do the exact same reseeding at the exact right time).

6.4 Getting Random Integers

The Problem Given a pseudo-random number generation interface that returns an array of bytes, you need to get random values in the various integer data types.

The Solution: For dealing with an integer that can contain any value, you may simply write bytes directly into every byte of the integer.

Discussion

To get a random integer value, all you need to do is fill the bytes of the integer

with random data.You can do this by casting a pointer to an integer to a binary

string, then passing it on to a function that fills a buffer with random bytes. For

example, use the following function to get a random unsigned integer, using the

spc_rand( ) interface.

unsigned int spc_rand_uint(void) { unsigned int res;

spc_rand((unsigned char *)&res, sizeof(unsigned int)); return res; }

This solution can easily be adapted to other integer data types simply by changing all the instances of unsigned int to the appropriate type.

31



3rd


6.5 Getting a Random Integer in a Range

The Problem: You want to choose a number in a particular range, with each possible value equally likely. For example, you may be simulating dice rolling and do not want any number to be more likely to come up than any other. You want all numbers in the range to be possible values, including both endpoints. That is, if you ask for a number between 1 and 6, you'd like both 1 and 6 to be as likely as 2, 3, 4, or 5.

The Solution: There are multiple ways to handle this problem. The most common is the least correct, and that is to simply reduce a random integer (modulo the size of the range and add to the minimum possible value. This can lead to slight biases in your random numbers, which can sometimes lead to practical attacks, because it means that some outputs are more likely than others.

Discussion

In all cases, you will start with a function that gives you a random unsigned number that can be any value, such as spc_rand_uint( ). You will mold numbers returned from this function into numbers in a specific range.

If you need random numbers in a particular range, the general approach is to get a number between zero and one less than the number of values in the range, and then adds the result to the smallest possible value in the range.

Ideally, when picking a random number in a range, you would like every possible value to be

equally likely. However, if you map from an arbitrary unsigned integer into a range, where the range does not divide evenly into the number of possible integers, you are going to run into problems.

Suppose you want to create a random number in a range using an unsigned 8-bit type. When you get a random unsigned 8-bit value, it can take on 256 possible values, from 0 to 255. If you are asking for a number between 0 and 9 inclusive, you could simply take a random value and reduce it modulo 10.

The problem is that the numbers 0 through 5 are more likely values than are 6 through 9. 26

possible values will reduce to each number between 0 and 5, but only 25 values will yield 6 through 9.

In this example, the best way to solve this problem is to discard any random numbers that fall in the range 250-255. In such a case, simply get another random value and try again. We took this approach in implementing the function spc_rand_range( ). The result will be a number greater than or equal to a minimum value and less than or equal to maximum value.

32



3rd


#include <limits.h> #include <stdlib.h>

int spc_rand_range(int min, int max) { unsigned int rado; int range = max - min + 1;

if (max < min) abort( ); /* Do your own error handling if appropriate.*/ do {

rado = spc_rand_uint( );

} while (rado > UINT_MAX - (UINT_MAX % range)); return min + (rado % range); }

You might worry about a situation where performance suffers because this code has to retry too many times. The worst case for this solution is when the size of the range is UINT_MAX / 2 + 1.

Even in such a case, you would not expect to call spc_rand_uint( ) very many times. The

average number of times it would be called here would be slightly less than two. While the worst case performance is theoretically unbounded, the chances of calling spc_rand_uint( ) more than a dozen times are essentially zero. Therefore, this technique will not have a significant performance impact for most applications.

If you are okay with some items being slightly more likely than others, there are two different

things you can do, both of which are fairly easy. First, you can perform a modulo operation and an addition to get the integer in the right range, and just not worry about the fact that some values are more likely than others:

#include <stdlib.h>

int spc_rand_range(int min, int max) { if (max < min) abort( ); return min + (spc_rand_uint( ) % (max - min + 1)); }

Of course, this solution clumps together all the values that are more likely to be chosen, which is somewhat undesirable. As an alternative, you can spread them out by using division and rounding down, instead of a simple modulus:

#include <limits.h> int spc_rand_range(int min, int max) {

33



3rd


if (max < min) abort( );

return min + (int)((double)spc_rand_uint( ) * (max - min + 1) / (double)UINT_MAX) % (max - min);

}

Note the modulo operation in this solution. That is to prevent getting a value that is out of range in the very rare occasion that spc_rand_uint( ) returns UINT_MAX.

34



3rd


Chapter 7: Race Conditions

7.1 Race Conditions:

The definition of a race condition is when two different execution contexts, whether they are threads or processes, are able to change a resource and interfere with one another. The typical flaw is to think that a short sequence of instructions or system calls will execute atomically, and that there’s no way another thread or process can interfere. Even when they’re presented with clear evidence that such a bug exists, many developers underestimate its severity. In reality, most system calls end up executing many thousands (sometimes millions) of instructions, and often they won’t complete before another process or thread gets a time slice.

Race conditions are commonly found under the following conditions:

■ More than one thread or process must write to the same resource. The resource could be shared memory, the file system (for example, by multiple web applications that manipulate data in a shared directory), other data stores like the Windows registry, or even a database. It could even be a shared variable! ■ Creating files or directories in common areas, such as directories for temporary files (like /tmp and /usr/tmp in UNIX-like systems).

7.2 Problem (1):

Race condition may be possible whenever two or more operations occur and one of the latter operations depends on the first. In the interval between events, an attacker may be able to force something to happen, changing the behavior of the system in ways not anticipated by the developer. Making this all work as an attacker requires a security-critical context, and explicit attention to timing and knowledge of the assumptions a developer may have made.

A cooperating process is one that can affect or be affected by other processes executing in the system. Cooperating processes may either directly share a logical address space (that is, both code and data), or be allowed to share data only through files. The former case is achieved through the use of lightweight processes or threads. Concurrent access to shared data may result in data inconsistency. In the next lines, we discuss a mechanism to ensure the orderly execution of cooperating processes that share a logical address space, so that data consistency is maintained.

Let us explain the shared-memory solution to the bounded-buffer problem. Our solution allows at most BUFFER-SIZE - 1 items in the buffer at the same time. Suppose that we want to modify the algorithm to remedy this deficiency. One possibility is to add an integer variable counter, initialized to 0. counter is

35



3rd


incremented every time we add a new item to the buffer, and is decremented every time we remove one item from the buffer. The code for the producer process can be as follows:

while (1) {

/* produce an item in nextproduced */ while (counter == BUFFER-SIZE)

; /* do nothing */

buffer [in] = nextproduced;

in = (in + I) % BUFFER-SIZE; counter++; }

The code for the consumer process can be as follows:

while (1) {

while (counter == 0) ; /* do nothing */

nextconsumed = buffer [out] ; out = (out + 1) % BUFFER-SIZE; counter--; /* consume the item in nextconsumed */

Although both the producer and consumer routines are correct separately, they may not function correctly when executed concurrently. As an illustration, suppose that the value of the variable counter is currently 5, and that the producer and consumer processes execute the statements "counter++" and "counter--" concurrently. Following the execution of these two statements,

the value of the variable counter may be 4, 5, or 6! The only correct result is counter == 5, which is generated correctly if the producer and consumer execute separately. We can show that the value of counter may be incorrect as follows. Note that the statement "counter++" may be implemented in machine language (on a typical machine) as:

registerl = counter registerl = registerl + 1 counter = registerl

where register1 is a local CPU register. Similarly, the statement "counter--" is implemented as follows:

register2 = counter register2 = register2 - 1 counter = register2

36



3rd


where again register2 is a local CPU register. Even though register1 and register2 may be the same physical register.

The concurrent execution of "counter++" and "counter--" is equivalent to a sequential execution where the lower-level statements presented previously are interleaved in some arbitrary order (but the order within each high level statement is preserved). One such interleaving is:

T0: producer execute registerl = counter {registerl = 5 )

T1: producer execute register1 = registerl + 1 {registerl = 6 ) T2: consumer execute register2 = counter {register2 = 5 )

T3: consumer execute register2 = register2 - 1 {register2 = 4) T4: producer execute counter = registerl {counter = 6 ) T5: consumer execute counter = register2 {counter = 4 )

Notice that we have arrived at the incorrect state "counter == 4" recording that there are four full buffers, when, in fact, there are five full buffers. If we reversed the order of the statements at T4 and T5, we would arrive at the incorrect state "counter == 6".

We would arrive at this incorrect state because we allowed both processes to manipulate the variable counter concurrently. A situation like this, where several processes access and manipulate the same data concurrently and the outcome of the execution depends on the particular order in which the access takes place, is called a race condition. To guard against the race condition above, we need to ensure that only one process at a time can be manipulating the variable counter. To make such a guarantee, we require some form of synchronization of the processes. Such situations occur frequently in operating systems as different parts of the system manipulate resources and we want the changes not to interfere with one another.

The Critical Section Problem:

Consider a system consisting of n processes {P0,P1, ..., P,-1). Each process has a segment of code, called a critical section, in which the process may be changing common variables, updating a table, writing a file, and so on. The important feature of the system is that, when one process is executing in its critical section, no other process is to be allowed to execute in its critical section.

37



3rd


Thus, the execution of critical sections by the processes is mutually exclusive in time. The critical-section problem is to design a protocol that the processes can use to cooperate. Each process must request permission to enter its critical section. The section of code implementing this request is the entry section. The critical section may be followed by an exit section. The remaining code is the remainder section.

Do { Entry section

Critical section

Exit section

Reminder section } while (1)

38



3rd


7.3 Problem (2):

Creating temporary files in a shared space as /tmp is common practice. Temporary files are susceptible to the problem that a smart attacker may be able to guess the filename. So we recommend the following strategy for creating a secure temporary files, especially if you must create one in a shared directory for some reason:

1. Pick a prefix for your filename. For example, /tmp/my_app. 2. Generate at least 64-bit of high-quality randomness from a

cryptographically secure source. 3. Base64 encode the random bits.

4. Concatenate the prefix with the encoded random data.

5. Set umask appropriately (0066 is usually good)

6. Use fopen( ) to create a file, opening it in the proper mode. 7. Delete the file immediately using unlik( ). Don’t worry, the file does not

go away until you close it. 8. Perform read, writes and seeks on the files as necessary.

9. Finally, close the file.

Never close and reopen the file if it lives in a directory that may be susceptible to a race condition. If you absolutely must close and reopen such a file, then you should be sure to use a secure directory, just as we recommend with regular files.

39



3rd


Chapter 8: Input/ Data Validation

8.1 Source of Input

Input validation starts with a fundamental supposition that all input is malicious

until proven otherwise. Whether input comes from a service, a file share, a user,

or a database, validate your input if the source is outside your trust boundary.

For example, if you call an external Web service that returns strings, how do

you know that malicious commands are not present? Also, if several

applications write to a shared database, when you read data, how do you know

whether it is safe?

There are some potential sources of input in computer system, which are:

- Command line - Environment variables Including PATH

- Files File descriptors

Configuration files

Temporary Files

- Databases - Network services

- Registry values

- System properties

8.2 Approaches to Validate Input

Data 1. Centralize the Approach

Make your input validation strategy a core element of your application design.

Consider a centralized approach to validation, for example, by using common

validation and filtering code in shared libraries. This ensures that validation

rules are applied consistently. It also reduces development effort and helps with

future maintenance.

In many cases, individual fields require specific validation, for example, with

specifically developed regular expressions. However, you can frequently factor

out common routines to validate regularly used fields such as e-mail addresses,

titles, names, postal addresses including ZIP or postal codes, and so on.

40



3rd


2. Do Not Rely on Client-Side Validation

Server-side code should perform its own validation. What if an attacker bypasses your client, or shuts off your client-side script routines, for example, by disabling JavaScript? Use client-side validation to help reduce the number of round trips to the server but do not rely on it for security. This is an example of defense in depth.

3. Be Careful with Canonicalization Issues

Data in canonical form is in its most standard or simplest form. Canonicalization is the process of converting data to its canonical form. File paths and URLs are particularly prone to canonicalization issues and many well-known exploits are a direct result of canonicalization bugs. For example, consider the following string that contains a file and path in its canonical form.

c:\temp\somefile.dat

The following strings could also represent the same file.

somefile.dat c:\temp\subdir\..\somefile.dat c:\ temp\ somefile.dat

..\somefile.dat c%3A%5Ctemp%5Csubdir%5C%2E%2E%5Csomefile.dat

In the last example, characters have been specified in hexadecimal form:

%3A is the colon character. %5C is the backslash character. %2E is the dot character.

You should generally try to avoid designing applications that accept input file names from the user to avoid canonicalization issues. Consider alternative designs instead. For example, let the application determine the file name for the user.

If you do need to accept input file names, make sure they are strictly formed before making security decisions such as granting or denying access to the specified file.

41



3rd


4. Constrain, Reject, and Sanitize Your Input

The preferred approach to validating input is to constrain what you allow from the beginning. It is much easier to validate data for known valid types, patterns, and ranges than it is to validate data by looking for known bad characters. When you design your application, you know what your application expects. The range of valid data is generally a more finite set than potentially malicious input. However, for defense in depth you may also want to reject known bad input and then sanitize the input.

To create an effective input validation strategy, be aware of the following approaches and their tradeoffs:

Constrain input.

Validate data for type, length, format, and range.

Reject known bad input.

Sanitize input.

Constrain Input

Constraining input is about allowing good data. This is the preferred approach. The idea here is to define a filter of acceptable input by using type, length, format, and range. Define what is acceptable input for your application fields and enforce it. Reject everything else as bad data.

Constraining input may involve setting character sets on the server so that you can establish the canonical form of the input in a localized way.

Validate Data for Type, Length, Format, and Range

Use strong type checking on input data wherever possible, for example, in the classes used to manipulate and process the input data and in data access routines. For example, use parameterized stored procedures for data access to benefit from strong type checking of input fields.

String fields should also be length checked and in many cases checked for appropriate format. For example, ZIP codes, personal identification numbers, and so on have well defined formats that can be validated using regular expressions. Thorough checking is not only good programming practice; it makes it more difficult for an attacker to exploit your code. The attacker may get through your type check, but the length check may make executing his favorite attack more difficult.

Reject Known Bad Input

Deny "bad" data; although do not rely completely on this approach. This approach is generally less effective than using the "allow" approach described earlier and it is best used in combination. To deny bad data assumes your application knows all the variations of malicious input. Remember that there are multiple ways to represent characters. This is another reason why "allow" is the preferred approach.

42



3rd


While useful for applications that are already deployed and when you cannot afford to make significant changes, the "deny" approach is not as robust as the "allow" approach because bad data, such as patterns that can be used to identify common attacks, do not remain constant. Valid data remains constant while the range of bad data may change over time.

Sanitize Input

Sanitizing is about making potentially malicious data safe. It can be helpful when the range of input that is allowed cannot guarantee that the input is safe. This includes anything from stripping a null from the end of a user-supplied string to escaping out values so they are treated as literals.

Another common example of sanitizing input in Web applications is using URL encoding or HTML encoding to wrap data and treat it as literal text rather than executable script. HtmlEncode methods escape out HTML characters, and UrlEncode methods encode a URL so that it is a valid URI request.

5. Encrypt sensitive cookie state

Cookies may contain sensitive data such as session identifiers or data that is used as part of the server-side authorization process. To protect this type of data from unauthorized manipulation, use cryptography to encrypt the contents of the cookie. Make sure that users do not bypass your checks. Make sure that users do not bypass your checks by manipulating parameters. URL parameters can be manipulated by end users through the browser address text box. For example, the URL http://www/.<YourSite>/<YourApp>/sessionId=10 has a value of 10 that can be changed to some random number to receive different output. Make sure that you check this in server-side code, not in client-side JavaScript, which can be disabled in the browser.

6. Validate all values sent from the client

Restrict the fields that the user can enter and modify and validate all values coming from the client. If you have predefined values in your form fields, users can change them and post them back to receive different results. Permit only known good values wherever possible. For example, if the input field is for a state, only inputs matching a state postal code should be permitted.

7. Do not trust HTTP header information

HTTP headers are sent at the start of HTTP requests and HTTP responses. Your Web application should make sure it does not base any security decision on information in the HTTP headers because it is easy for an attacker to manipulate the header. For example, the referer field in the header contains the URL of the Web page from where the request originated. Do not make any security decisions based on the value of the referer field, for example, to check whether the request originated from a page generated by the Web application, because the field is easily falsified.

43



3rd


Chapter 9: Password Authentication

9.1 Introduction

Some security experts argue that passwords do not make for good security. But

passwords can give a highly effective supplement to other kinds of

authentications. Disagreement by all the security experts in the world cannot kill

the password. The fact in the matter is that passwords are likely to be used for

many years to come, because they seem very simple.

9.2 Password Selection

People select passwords that are easy to remember, this fact will narrow the

effectiveness of passwords. There are many programs that help an attacker to

guess passwords intelligently.

Many software systems force the user to provide a password that meets basic

quality standards. After a user types in the password, the software checks the

quality of the password, and if there is a problem with it, then the user is told

and must choose another password.

Also, the software can give the user recommendations for choosing good

passwords. This is an okay idea, but it often backfires if the suggested process

isn’t absolutely excellent, because if you give people a simple pattern to use,

they are likely to follow it too closely. So people will pick passwords that

appear to be well chosen, but are not. For example, we have seen programs give

advice similar to the following:

Take two words that are easy for you to remember, and combine them, sticking punctuation in the middle, for example, good!advice.

This advice is not very good, actually. Most passwords-cracking programs including Crack itself try this try of pattern, and break the password. Let’s try some slightly better advice:

44



3rd


One suggestions is to use a date that is important to you (may be your mother’s

birthday), and then combine it with a piece of punctuation and some text that is

easy to remember, such as mom’s initials. For example, 033156!glm.

This is a much better password than good!advice. It may have been an okay

password, except that passwords chosen by people using your program are

bound to look similar. Crack programs adapt to check passwords that are

constructed using this technique. While they are at it, they swap the order of the

piece.

Let’s look at some advice that’s even better:

Take a sentence that you can easily remember, such as a famous song. Use the

first letters of each word, and use any punctuations. For example, “My name is

Jone King of king!” and use the password MniJ,kok!.

This advice can be easily followed, and is a lot harder to attack than the

preceding two pieces of advice. Of course, some people will get lazy and steal

the password. You need to make sure to reject passwords that are obvious from

the advice.

Some reasonable strategy is to let the user try few passwords if the system do not accept one and after a few failures ,the system will give a piece of advice

More Advice

Sometimes it is better to give a generic advice, without password examples, like:

Password should be at least eight characters. Don’t be afraid of using long password. Avoid password that are in any way similar to other passwords you have.

Avoid use words that may be found in dictionary, names book, on a map,

and so forth. Consider numbers and/ or punctuations into your password.

45



3rd


9.3 Password Authentication

To authenticate the password follow the steps:

1. Read the user name. 2. Figure out the key that is used to encrypt the original password. 3. Read the password. 4. Run the decrypt using the key. 5. Check the password with the memory stored. 6. Check the two strings to be equally.

These steps do not consider any security action when the user try to log in to an

account but fails. So, the program must stops after a three bad login attempts.

But so what? People can just run the program over and over again. As a result,

attackers have unlimited time to try to guess the password of account into which

they wish to break. It is almost as bad as if they had a copy of the hashed

password. What we have created is not a password system; it’s only a delay

mechanism!

One thing we can do is to lock the account after some fairly small number of

bad login attempts (say five). Users should then be forced to interact with an

administrator or customer support to get their account unlocked. A complication

with this scheme is that it is difficult to authenticate a user when they go to get

the locked account unlocked. How does one know it is not an attacker who

happens to know a target’s social security number, and as forth?

The best way is to have the person provide their actual password. The problem

is obvious: How do you distinguish people who genuinely can’t remember their

passwords from attackers pulling a social engineering attack? An attacker will

surly say, “I can’t remember my password!” over the phone, one the lockout

number has been exceeded. One mitigation measure is to record when login

failures occur. Automated attacks can cause many failed attempts within a

single second or two. Another thing to do is to set the number of attempts

before locking the account at approximately 50. If the user has actually

forgotten the password, the user is unlikely to try 50 different passwords. A

much more likely approach is to try calling customer support. Therefore, if the

threshold of 50 is reached, then an attacker is fairly likely, and you should

expect the customer to be able to provide an actual password.

46



3rd


Chapter 10: Access Control

10.1 Introduction

Access control is a major issue for application developers. An application must always be sure to protect its resources from unauthorized access. This requires properly setting permissions on created files, allowing only authorized hosts to connect to any network ports, and properly handling privilege elevation and surrendering. Applications must also defend against race conditions that may occur when opening files—for example, the Time of Check, Time of Use (TOCTOU) condition.

10.2 Understanding the Unix Access Control Model

10.2.1 Problem

You want to understand how access control works on Unix systems.

10.2.2 Solution

Unix traditionally uses a user ID-based access control system. Some newer variants implement additional access control mechanisms, such as Linux's implementation of POSIX capabilities. Because additional access control mechanisms vary greatly from system to system, we will discuss only the basic user ID system in this recipe.

10.2.3 Discussion

Every process running on a Unix system has a user ID assigned to it. In reality, every process actually has three user IDs assigned to it: an effective user ID, a real user ID, and a saved user ID. The effective user ID is the user ID used for most permission checks. The real user and saved user IDs are used primarily for determining whether a process can legally change its effective user ID.

In addition to user IDs, each process also has a group ID. As with user IDs, there are actually three group IDs: an effective group ID, a real group ID, and a saved group ID. Processes may belong to more than a single group. The operating system maintains a list of groups to which a process belongs for each process. Group-based permission checks check the effective group ID as well as the process's group list.

47



3rd


10.3 Understanding the Windows Access Control Model

10.3.1 Problem

You want to understand how access control works on Windows systems.

10.3.2 Solution

Versions of Windows before Windows NT have no access control. Windows 95, Windows 98, and Windows ME are all intended to be single-user desktop operating systems and thus have no need for access control. Windows NT, Windows 2000, Windows XP, and Windows Server 2003 all use a system of access control lists (ACLs).

Most users do not understand the Windows access control model and generally regard it as being overly complex. However, it is actually rather straightforward and easy to understand. Unfortunately, from a programmer's perspective, the API for dealing with ACLs is not so easy to deal with.

10.3.3 Discussion

All Windows resources, including files, the registry, synchronization primitives (e.g., mutexes and events), and IPC mechanisms (e.g., pipes and mailslots), are accessed through objects, which may be secured using ACLs. Every ACL contains a discretionary access control list (DACL) and a system access control list (SACL). DACLs determine access rights to an object, and SACLs determine auditing (e.g., logging) policy. In this recipe, we are concerned only with access rights.

10.4 Determining Whether a User Has Access to a File 10.4.1.Problem Your program is running with extra permissions because its executable has the setuid or setgid bit set. You need to determine whether the user running the program will be able to access a file without the extra privileges granted by setuid or setgid.

10.4.2 Solution

Temporarily drop privileges to the user and group for which access is to be checked. With the process's privileges lowered, perform the access check, then restore privileges to what they were before the check.

10.4.3 Discussion

It is always best to allow the operating system to do the bulk of the work of performing access checks. The only way to do so is to manipulate the privileges under which the process is running.

48



3rd


When performing access checks on files, you need to be careful to avoid the types of race conditions known as Time of Check, Time of Use (TOCTOU), which are illustrated in Figure 9-1 and Figure 9-2. These race conditions occur when access is checked before opening a file. The most common way for this to occur is to use the access( ) system call to verify access to a file, and then to use open( ) or fopen( ) to open the file if the return from access( ) indicates that access will be granted.

The problem is that between the time the access check via access( ) completes

and the time open( ) begins (both system calls are atomic within the operating

system kernel), there is a window of vulnerability where an attacker can replace

the file that is being operated upon. Let's say that a program uses access( ) to

check to see whether an attacker has write permissions to a particular file, as

shown in Figure 9-1. If that file is a symbolic link, access( ) will follow it, and

report that the attacker does indeed have write permissions for the underlying

file. If the attacker can change the symbolic link after the check occurs, but

before the program starts using the file, pointing it to a file he couldn't otherwise

access, the privileged program will end up opening a file that it shouldn't, as

shown in Figure 9-2. The problem is that the program can manipulate either file,

and it gets tricked into opening one on behalf of the user that it shouldn't have.

Figure 10-1. Stage 1 of a TOCTOU race condition: Time of Check

49



3rd


Figure 10-2. Stage 2 of a TOCTOU race condition: Time of Use

10.5 Determining Whether a Directory Is Secure 10.5.1 Problem Your application needs to store sensitive information on disk, and you want to ensure that the directory used cannot be modified by any other entity on the system besides the current user and the administrator. That is, you would like a directory where you can modify the contents at will, without having to worry about future permission checks. 10.5.2 Solution

Check the entire directory tree above the one you intend to use for unsafe permissions.

Specifically, you are looking for the ability for users other than the owner and the superuser (the Administrator account on Windows) to modify the directory. On Windows, the required directory traversal cannot be done without introducing race conditions and a significant amount of complex path processing. The best advice we can offer, therefore, is to consider home directories (typically x:\Documents and Settings\User, where x is the boot drive and User is the user's account name) the safest directories. Never consider using temporary directories to store files that may contain sensitive data.

10.5.3 Discussion

Storing sensitive data in files requires extra levels of protection to ensure that the data is not compromised. An often overlooked aspect of protection is ensuring that the directories that contain files (which, in turn, contain sensitive data) are safe from modification.

This may appear to be a simple matter of ensuring that the directory is protected against any other users writing to it, but that is not enough. All the directories in the path must also be protected against any other users writing to them. This means that the same user who will own the file containing the sensitive data also owns the directories, and that the directories are all protected against other users modifying them.

50



3rd


The reason for this is that when a directory is writable by a particular user, that user is able to rename directories and files that reside within that directory. For example, suppose that you want to store sensitive data in a file that will be placed into the directory /home/myhome/stuff/securestuff. If the directory /home/myhome/stuff is writable by another user, that user could rename the directory securestuff to something else. The result would be that your program would no longer be able to find the file containing its sensitive data.

Even if the secure stuff directory is owned by the user who owns the file containing the sensitive data, and the permissions on the directory prevent other users from writing to it, the permissions that matter are on the parent directory, /home/myhome/stuff. This same problem exists for every directory in the path, right up to the root directory.

10.6 Erasing Files Securely 10.6.1 Problem You want to erase a file securely, preventing recovery of any data via "undelete" tools or any inspection of the disk for data that has been left behind.

10.6.2 Solution

Write over the data in the file multiple times, varying the data written each time. You should write both random and patterned data for maximum effectiveness.

10.6.3 Discussion

Securely deleting files from disk is not as simple as issuing a system call to delete the file from the filesystem. The first problem is that most delete operations do not do anything to the data; they merely delete any underlying metadata that the filesystem uses to associate the file contents with the filename. The storage space where the actual data is stored is then marked free and will be reclaimed whenever the filesystem needs that space.

The result is that to truly erase the data, you need to overwrite it with nonsense before the filesystem delete operation is performed. Many times, this overwriting is implemented by simply zeroing all the bytes in the file. While this will certainly erase the file from the perspective of most conventional utilities, the fact that most data is stored on magnetic media makes this more complicated.

More sophisticated tools can analyze the actual media and reveal the data that was previously stored on it.

This type of data recovery has a limit, however. If the data is sufficiently overwritten on the media, it does become unrecoverable, masked by the new data that has overwritten it. A variety of factors, such as the type of data written and the characteristics of the media, determine the point at which the interesting data becomes unrecoverable.

51



3rd


Chapter 11: Database Security

11.1 Introduction

Database security deals with all various aspects of protecting the database content, its owners, and its users. It ranges from protection from intentional unauthorized database uses to unintentional database accesses by unauthorized entities (e.g., a person or a computer program).

The following are major areas of database security (among many others).

Access control

Database access control deals with controlling who (a person or a certain computer program) is allowed to access what information in the database. The information may comprise specific database objects (e.g., record types, specific records, data structures), certain computations over certain objects (e.g., query types, or specific queries), or utilizing specific access paths to the former (e.g., using specific indexes or other data structures to access information).

Database access controls are set by special authorized (by the database owner) personnel that uses dedicated protected security DBMS interfaces.

Data security

The definition of data security varies and may overlap with other database security aspects. Broadly it deals with protecting specific chunks of data, both physically (i.e., from corruption, or destruction, or removal; e.g., see Physical security), or the interpretation of them, or parts of them to meaningful information (e.g., by looking at the strings of bits that they comprise, concluding specific valid credit-card numbers; e.g., see Data encryption).

Database audit

Database audit primarily involves monitoring that no security breach, in all aspects, has happened. If security breach is discovered then all possible corrective actions are taken.

52



3rd


11.2 Field Protection:

We shouldn’t always assume that other people with database access are actually trustworthy. Therefore, there is a need to protect fields in a database from the prying eyes of the person who has valid access to administer the database. For example, we may wish to store passwords for an end application as cryptographic hashes instead of plain-text strings. We may also wish to keep credit card numbers and the like encrypted.

Instead of relying on built-in-functionality of encryption, you should perform your own encryption and your own hashing at the application level using algorithms you trust. This is encrypt the data before storing it, and decrypts it on retrieval. You will likely need to take the binary output of the cipher and encode it to fit it into the database, because SQL commands do not accept arbitrary binary strings. We recommend encoding data using the base64 encoding algorithm, which does a good job of minimizing the size of the resulting data.

One problem with self-encryption data in a database is that the database itself provides no way of searching such data efficiently. The only way to solve this problem is to retrieve all of the relevant data, and search through it after decryption.

A bigger problem with encryption fields is that you generally end up expanding the data (because the fields generally must be stored as text and not the binary that results from an encryption operation). This may not be possible in some environments without expanding you tables. This is often prohibitive, especially if you’ve got a table design that has been highly tuned to match the underlying hardware or is something that can’t be changed because it’ll break many existing applications that expect a particular table layout.

53



3rd


Chapter 12: Copyright & Copy Protection

12.1 Definition of a Copyright

A copyright is a form of protection provided by the laws to authors of "original works of authorship." This includes literary, dramatic, musical, artistic and certain other creative works. Material not protected by copyright (or otherwise protected) is available for use by anyone without the author's consent. A copyright holder can prevent others from copying, performing or otherwise using the work without his or her consent.

Copyright protection is automatic under international law, but in the event that your work is infringed evidence may be required to support your claim. It also helps to deter infringement (particularly from those who do not understand copyright) if you make it clear that your work is protected under copyright law. So ensuring the best protection for your work relies on several factors.

Figure (12-1): Compare between Digital and Paper-based

Copyright Protection System 54



3rd


There are four simple steps you can take that can help ensure your work is safe.

1. Ensure your work is properly marked.

A correctly worded notice will deter infringement, as it states that the work is protected under law.

Although a copyright notice is not required, (work is automatically subject to copyright protection under law), displaying a notice shows that you have an awareness of copyright and take infringements of your work seriously.

2. Register your work.

If your work is infringed and your claim to copyright is disputed (i.e. in a plagiarism case - where the other party claims the work is theirs), you may need evidence to help prove your claim.

This valuable evidence can be provided by our copyright registration service that provides verifiable proof of the date and content of your work. As specialists in this area, we ensure that you have the very best evidence to support your rights, while our service policies ensure that the evidence is always available when you need it.

For information on registration, please see our fact sheet P-04: Registering copyright work.

3. Keep or register supporting evidence.

Supporting evidence falls into two categories:

Evolution of ideas

This is evidence of the progression of the work. Early drafts, synopsis, rough recordings, sketches, etc. are all evidence that the work progressed over time, rather than being copied from elsewhere. Although it is possible to fake such evidence, it is often time consuming to do so, so it can be fairly good evidence to demonstrate that you created the work from scratch over a period of time.

Footprints or watermarking

55



3rd


This is normally evidence inserted into finished documents that will identify the author in some way, such as deliberate mistakes, or hidden data that can be read using special applications.

For more details see our page on supporting evidence.

Agreement between co-authors.

If your work is a joint venture, be sure you know exactly where you stand, who will own what rights, and what happens when someone leaves.

For more details, see our page on agreements between co-authors.

12.2 What does Copyright Protect?

Copyright, a form of intellectual property law, protects original works of

authorship including literary, dramatic, musical, and artistic works, such as

poetry, novels, movies, songs, computer software, and architecture. Copyright

does not protect facts, ideas, systems, or methods of operation, although it may

protect the way these things are expressed.

12.3 Copy Protection

Refers to techniques used to prevent the unauthorized copying of

software. The idea of copy-protected software was created by software

manufacturers who wanted to prevent software piracy -- users copying

programs and giving them to friends and colleagues free of charge.

As enticing an idea as it may be, copy protection has not proved to be a viable

strategy. For one, it is practically impossible to create software that cannot be

copied by a knowledgeable programmer. Second, many consumers shy away

from copy-protected software because backup copies are difficult to make.

Thus, if their original copy of the software is damaged, the user must contact the

manufacturer for a new copy. Finally, some copy-protection techniques can

56



3rd


actually damage other software on the system. For these reasons, copy-protected software is becoming less common.

Most software producers now protect their programs by issuing registration

numbers with each package. When you install the software, you must enter the

registration number. This does not prevent all piracy, but it limits it. In addition,

users cannot get updates to a product unless they own the original diskettes and

documentation.

An alternative strategy for dealing with the problem of software piracy is

shareware, where users are actually encouraged to copy and disseminate

programs. Shareware publishers rely on people's honesty to pay for the products

used.

57

University of Technology


3rd

Class

58

Lecturer: Osama Younus


Chapter 13: Session management, Session hijacking, Threat modeling

13.1: Session management: [Luke Murphy, secure session management: preventing security

voids in web applications, 2005] Many companies that maintain highly confidential data perform a background check before a candidate can

be hired. The background check may include fingerprinting, checking state and federal criminal records,

financial records and driving records. The process is extensive and costly. Upon successful completion of the

background check, the employee is granted an ID card that allows them access to company site and

resources. This background check is not performed daily, as it is too expensive. The employee only needs to

present their identification to be allowed into work, foregoing the initial authentication routine. This is a

literal example of session management. Sessions allow a web-based system to avoid repeatedly performing

authentication. Web applications perform an authentication process to determine if a user should be granted

access to the web based resource much like companies use a background check to determine if an individual

should be granted access to the company’s resources. The user is granted a session ID when they have

successfully authenticated (i.e. presented a valid login name and password). This session ID can be presented

wherever authentication is necessary to avoid repeating the login/password process. This is similar to the

employee identification that allows them into the building. The session ID itself is simply a string of

characters or numbers and functions much like a social security number. The server remembers that the

session ID (SID) was given to the user and allows access when it is presented. Having the SID circumvents

having to provide the login name and password and is thus of great value to potential hackers. Session IDs

may be valuable to hackers, but they oftentimes are taken for granted by developers.

Good session management is the barrier between the public and the data stored in the system. It is as

important as the data the system maintains. Protecting the session ID is critical to the security of an online

system. Sessions allow web applications to maintain state. After the user logs in, the server and client will

operate together to maintain an authenticated state until the user logs out. Hyper-Text Transfer Protocol

(HTTP) is a stateless protocol, and thus, special techniques are required to create stateful web applications.

Three methods are used to perform this function: cookies, GET form data, and POST form data. Developers

use one or more of these methods to propagate the SID from one page to the next so that a users session can

be maintained.

13.2: Session hijacking: Session hijacking is the process by which a malicious user acquires a valid session identifier after it has been

assigned and inherits that individual’s permissions. They “hijack” a valid session. In the real world, a

malefactor who finds an employee badge, copies it and decides to gallivant around the company’s facilities

has performed a similar action. The malefactor has your access but he is not you, and likely has different

intentions.

Sessions are hijacked by one of three ways: prediction, brute force and interception.

13.2.1: Prediction Prediction occurs when a malefactor realizes that a pattern exists between session IDs. For example, some

web based systems increment the session ID each time a user logs on. Knowing one session ID allows

malicious users to predict the previous and next ones.

Some session IDs are more predictable then others. Some SIDs may be hashed or contain information such

as IP addresses or timestamps. This information makes prediction more difficult, but not unpredictable.



3rd

Class

59



13.2.2: Brute Force Attack A brute force attack is a simple yet potentially effective method for determining a session identifier. A brute

force attack occurs when a malicious user repeatedly tries numerous session identifiers until he or she

happens upon a valid one. Although it is not complicated, it can be effective if the web-based system is not

designed to defend against such an attack.

13.2.3: Interception Interception is a common method of identity theft. Identity thieves will often search through trash for

information such as credit card and social security numbers. The criminal knows the number is valid because

they intercepted it from you.

The same principle applies to session management. Interception occurs in a web application when a

malicious user is able to extract data allowing him or her to determine the session identifier. The methods to

intercept session IDs are generally more complicated than the methods of brute force and prediction.

13.3: Threat modeling [https://www.owasp.org/index.php/Application_Threat_Modeling]

Threat modeling is an approach for analyzing the security of an application. It is a structured approach that

enables you to identify, quantify, and address the security risks associated with an application. Threat

modeling is not an approach to reviewing code, but it does complement the security code review process.

The inclusion of threat modeling in the SDLC can help to ensure that applications are being developed with

security built-in from the very beginning. This, combined with the documentation produced as part of the

threat modeling process, can give the reviewer a greater understanding of the system. This allows the

reviewer to see where the entry points to the application are and the associated threats with each entry point.

The concept of threat modeling is not new but there has been a clear mindset change in recent years. Modern

threat modeling looks at a system from a potential attacker's perspective, as opposed to a defender's

viewpoint. Microsoft have been strong advocates of the process over the past number of years. They have

made threat modeling a core component of their SDLC, which they claim to be one of the reasons for the

increased security of their products in recent years.

When source code analysis is performed outside the SDLC, such as on existing applications, the results of

the threat modeling help in reducing the complexity of the source code analysis by promoting an in-depth

first approach vs. breadth first approach. Instead of reviewing all source code with equal focus, you can

prioritize the security code review of components whose threat modeling has ranked with high risk threats.

The threat modeling process can be decomposed into 3 high level steps:

Step 1: Decompose the Application. The first step in the threat modeling process is concerned with gaining

an understanding of the application and how it interacts with external entities. This involves creating use-

cases to understand how the application is used, identifying entry points to see where a potential attacker

could interact with the application, identifying assets i.e. items/areas that the attacker would be interested in,

and identifying trust levels which represent the access rights that the application will grant to external

entities. This information is documented in the Threat Model document and it is also used to produce data

flow diagrams (DFDs) for the application. The DFDs show the different paths through the system,

highlighting the privilege boundaries.



3rd

Class

60



Step 2: Determine and rank threats. Critical to the identification of threats is using a threat categorization

methodology. A threat categorization such as STRIDE can be used, or the Application Security Frame (ASF)

that defines threat categories such as Auditing & Logging, Authentication, Authorization, Configuration

Management, Data Protection in Storage and Transit, Data Validation, Exception Management. The goal of

the threat categorization is to help identify threats both from the attacker (STRIDE) and the defensive

perspective (ASF). DFDs produced in step 1 help to identify the potential threat targets from the attacker's

perspective, such as data sources, processes, data flows, and interactions with users. These threats can be

identified further as the roots for threat trees; there is one tree for each threat goal. From the defensive

perspective, ASF categorization helps to identify the threats as weaknesses of security controls for such

threats. Common threat-lists with examples can help in the identification of such threats. Use and abuse cases

can illustrate how existing protective measures could be bypassed, or where a lack of such protection exists.

The determination of the security risk for each threat can be determined using a value-based risk model such

as DREAD or a less subjective qualitative risk model based upon general risk factors (e.g. likelihood and

impact).

Step 3: Determine countermeasures and mitigation. A lack of protection against a threat might indicate a

vulnerability whose risk exposure could be mitigated with the implementation of a countermeasure. Such

countermeasures can be identified using threat-countermeasure mapping lists. Once a risk ranking is assigned

to the threats, it is possible to sort threats from the highest to the lowest risk, and prioritize the mitigation

effort, such as by responding to such threats by applying the identified countermeasures. The risk mitigation

strategy might involve evaluating these threats from the business impact that they pose and reducing the risk.

Other options might include taking the risk, assuming the business impact is acceptable because of

compensating controls, informing the user of the threat, removing the risk posed by the threat completely, or

the least preferable option, that is, to do nothing.



3rd

Class

61



Chapter 14: Attack Trees

14.1: Enter Attack trees [https://www.schneier.com/paper-attacktrees-ddj-ft.html]

Attack trees provide a formal, methodical way of describing the security of systems, based on varying

attacks. Basically, you represent attacks against a system in a tree structure, with the goal as the root node

and different ways of achieving that goal as leaf nodes.

The next figure, for instance, is a simple attack tree against a physical safe. The goal is opening the safe. To

open the safe, attackers can pick the lock, learn the combination, cut open the safe, or install the safe

improperly so that they can easily open it later. To learn the combination, they either have to find the

combination written down or get the combination from the safe owner. And so on. Each node becomes a

subgoal, and children of that node are ways to achieve that subgoal. (Of course, this is just a sample attack

tree, and an incomplete one at that. How many other attacks can you think of that would achieve the goal?)

Note that there are AND nodes and OR nodes (in the figures, everything that isn't an AND node is an OR

node). OR nodes are alternatives -- the four ways to open a safe, for example. AND nodes represent different

steps toward achieving the same goal. To eavesdrop on someone saying the safe combination, attackers have

to eavesdrop on the conversation AND get safe owners to say the combination. Attackers can't achieve the

goal unless both subgoals are satisfied.

That's the basic attack tree. Once you have it completed, you can assign values -- I (impossible)

and P(possible) in Figure 1 -- to the various leaf nodes, then make calculations about the nodes. (Again, this

is only an illustrative example; do not take the values as an indication of how secure my safe really is.) Once

you assign these values -- presumably this assignment will be the result of painstaking research on the safe

itself -- you can calculate the security of the goal. The value of an OR node is possible if any of its children

are possible, and impossible if all of its children are impossible. The value of an AND node is possible only

if all children are possible, and impossible otherwise; see next figure.

https://www.schneier.com/paper-attacktrees-fig1.html



3rd

Class

62



The dotted lines in the previous figure show all possible attacks -- a hierarchy of possible nodes, from a leaf

to the goal. In this sample system, there are two possible attacks: Cutting open the safe, or learning the

combination by bribing the owner of the safe. With this knowledge, you know exactly how to defend this

system against attack.

Assigning "possible" and "impossible" to the nodes is just one way to look at the tree. Any Boolean value

can be assigned to the leaf nodes and then propagated up the tree structure in the same manner: easy versus

difficult, expensive versus inexpensive, intrusive versus nonintrusive, legal versus illegal, special equipment

required versus no special equipment. The next figure shows the same tree with another Boolean node value.

Assigning "expensive" and "not expensive" to nodes is useful, but it would be better to show exactly how

expensive. It is also possible to assign continuous values to nodes. The next figure shows the tree with



3rd

Class

63



different costs assigned to the leaf nodes. Like Boolean node values, these can propagate up the tree as well.

OR nodes have the value of their cheapest child; AND nodes have the value of the sum of their children.

In the figure, the costs have propagated up the tree, and the cheapest attack has been highlighted.

Again, this tree can be used to determine where a system is vulnerable. The next figure shows all attacks that

cost less than $100,000. If you are only concerned with attacks that are less expensive (maybe the contents of

the safe are only worth $100,000), then you should only concern yourself with those attacks.

There are many other possible continuous node values, including probability of success of a given attack,

likelihood that an attacker will try a given attack, and so on.



3rd

Class

64



14.2: Nodes and Their Values

In any real attack tree, nodes will have many different values corresponding to many different variables, both

Boolean and continuous. Different node values can be combined to learn even more about a

system's vulnerabilities. The next figure, for instance, determines the cheapest attack requiring no special

equipment. You can also find the cheapest low-risk attack, most likely nonintrusive attack, best low-skill

attack, cheapest attack with the highest probability of success, most likely legal attack, and so on. Every time

you query the attack tree about a certain characteristic of attack, you learn more about the system's security.

To make this work, you must marry attack trees with knowledge about attackers. Different attackers have

different levels of skill, access, risk aversion, money, and so on. If you're worried about organized crime, you

have to worry about expensive attacks and attackers who are willing to go to jail. If you are worried about

terrorists, you also have to worry about attackers who are willing to die to achieve their goal. If you're

worried about bored graduate students studying the security of your system, you usually don't have to worry

about illegal attacks such as bribery and blackmail. The characteristics of your attacker determine which

parts of the attack tree you have to worry about.

Attack trees also let you play "what if" games with potential countermeasures. In the figure, for example, the

goal has a cost of $20,000. This is because the cheapest attack requiring no special equipment is bribing the

person who knows the combination. What if you implemented a countermeasure -- paying that person more

so that he is less susceptible to bribes? If you assume that the cost to bribe him is now $80,000 (again, this is

an example; in the real world you'd be expected to research exactly how a countermeasure affects the node

value), then the cost increases to $60,000 (presumably to hire the thugs to do the threatening).

14.3: A PGP Example

The next figure is an attack tree for the popular PGP e-mail security program. Since PGP is a complex

program, this is a complex tree, and it's easier to write it in outline form than graphically. PGP has several

security features, so this is only one of several attack trees for PGP. This particular attack tree has "read a

message encrypted with PGP" as its goal. Other goals might be: "forge someone else's signature on a





3rd

Class

65



message," "change the signature on a message," "undetectibly modify a PGP-signed or PGP-encrypted

message," and so on.

What immediately becomes apparent from the attack tree is that breaking the RSA or IDEA encryption

algorithms are not the most profitable attacks against PGP. There are many ways to read someone's PGP-

encrypted messages without breaking the cryptography. You can capture their screen when they decrypt and

read the messages (using a Trojan horse like Back Orifice, a TEMPEST receiver, or a secret camera), grab

their private key after they enter a passphrase (Back Orifice again, or a dedicated computer virus), recover

their passphrase (a keyboard sniffer, TEMPEST receiver, or Back Orifice), or simply try to brute force their

passphrase (I can assure you that it will have much less entropy than the 128-bit IDEA keys that it

generates). In the scheme of things, the choice of algorithm and the key length is probably the least important

thing that affects PGP's overall security. PGP not only has to be secure, but it has to be used in an

environment that leverages that security without creating any new insecurities.



3rd

Class

66





3rd

Class

67



14.4: Creating Attack Trees

How do you create an attack tree like this? First, you identify the possible attack goals. Each goal forms a

separate tree, although they might share subtrees and nodes. Then, try to think of all attacks against each

goal. Add them to the tree. Repeat this process down the tree until you are done. Give the tree to someone

else, and have him think about the process and add any nodes he thinks of. Repeat as necessary, possibly

over the course of several months. Of course there's always the chance that you forgot about an attack, but

you'll get better with time. Like any security analysis, creating attack trees requires a certain mindset and

takes practice.

Once you have the attack tree, and have researched all the node values (these values will change over time,

both as attacks become easier and as you get more exact information on the values), you can use the attack

tree to make security decisions. You can look at the values of the root node to see if the system's goal is

vulnerable to attack. You can determine if the system is vulnerable to a particular kind of attack; password

guessing, for instance. You can use the attack tree to list the security assumptions of a system; for example,

the security of PGP might assume that no one could successfully bribe the programmers. You can determine

the impact of a system modification or a new vulnerability discovery: Recalculate the nodes based on the

new information and see how the goal node is affected. And you can compare and rank attacks -- which is

cheaper, which is more likely to succeed, and the like.

One of the surprising things that comes out of this kind of analysis is that the areas people think of as

vulnerable usually aren't. With PGP, for example, people generally worry about key length. Should they use

1024-bit RSA or 2048-bit RSA? Looking at the attack tree, though, shows that the key length of RSA doesn't

really matter. There are all sorts of other attacks -- installing a keyboard sniffer, modifying the program on

the victim's hard drive -- that are much easier than breaking the RSA public key. Increasing the key length

from 1024 bits to 2048 bits is like putting an enormous stake into the ground and hoping the enemy runs

right into it, as opposed to building a lower palisade around the target. Attack trees give you perspective on

the whole system.

One of the things that really makes attack trees valuable is that they capture knowledge in a reusable form.

Once you've completed the PGP attack tree, you can use it in any situation that uses PGP. The attack tree

against PGP becomes part of a larger attack tree. For example, the next figure shows an attack tree whose

goal is to read a specific message that has been sent from one Windows 98 computer to another. If you look

at the root nodes of the tree, the entire attack trees for PGP and for opening a safe fit into this attack tree.

This scalability means that you don't have to be an expert in everything. If you're using PGP in a system, you

don't have to know the details of the PGP attack tree; all you need to know are the values of the root node. If

you're a computer-security expert, you don't have to know the details about how difficult a particular model

of safe is to crack; you just need to know the values of the root node. Once you build up a library of attack

trees against particular computer programs, door and window locks, network security protocols, or whatever,

you can reuse them whenever you need to. For a national security agency concerned about

compartmentalizing attack expertise, this kind of system is very useful.




3rd

Class

68



Attack trees provide a formal methodology for analyzing the security of systems and subsystems. They

provide a way to think about security, to capture and reuse expertise about security, and to respond to

changes in security. Security is not a product -- it's a process. Attack trees form the basis of understanding

that process.



3rd

Class

69



Chapter 15: Use Case, Misuse Case, Threat Modeling Tools

15.1: Use case [http://whatis.techtarget.com/definition/use-case-diagram]

A use case is a methodology used in system analysis to identify, clarify, and organize system requirements.

In this context, the term "system" refers to something being developed or operated, such as a mail-order

product sales and service Web site. Use case diagrams are employed in UML (Unified Modeling Language),

a standard notation for the modeling of real-world objects and systems.

System objectives can include planning overall requirements, validating a hardware design, testing

and debugging a software product under development, creating an online help reference, or performing a

consumer-service-oriented task. For example, use cases in a product sales environment would include item

ordering, catalog updating, payment processing, and customer relations. A use case diagram contains four

components.

The boundary, which defines the system of interest in relation to the world around it.

The actors, usually individuals involved with the system defined according to their roles.

The use cases, which are the specific roles played by the actors within and around the system.

The relationships between and among the actors and the use cases.

A use case diagram looks something like a flowchart. Intuitive symbols represent the system elements. Here's

a simple example:

http://searchsoftwarequality.techtarget.com/definition/use-case

http://searchsoa.techtarget.com/definition/Web-site

http://searchsoftwarequality.techtarget.com/definition/Unified-Modeling-Language

http://searchcio-midmarket.techtarget.com/definition/hardware

http://searchsoftwarequality.techtarget.com/definition/debugging

http://searchsoa.techtarget.com/definition/software

http://whatis.techtarget.com/definition/flowchart



3rd

Class

70



15.2: Misuse case[https://www.owasp.org/index.php/Detail_misuse_cases]

15.2.1: Identify misuse cases

Misuse cases are identical to use cases, except that they are meant to detail common attempted abuses of the

system. Like use cases, misuse cases require understanding the actors that are present in the system. Those

actors should be mapped to capabilities, if possible. Misuse cases should be designed for each actor, and one

should also consider uses cases for nefarious collaborating actors.

As with normal use cases, one should expect misuse cases to require adjustment over time. Particularly, it is

common to start with high-level misuse cases, and refine them as the details of the system are better

understood.

Determining misuse cases generally constitutes a brainstorming activity. There are three good starting points

for structured brainstorming:



3rd

Class

71



First, one can start with a pre-existing knowledge base of common security problems and determine

whether an attacker may have cause to think such a vulnerability is possible in the system. Then, one

should attempt to describe how the attacker will leverage the problem if it exists.

Second, one can brainstorm on the basis of a list of system resources. For each resource, attempt to

construct misuse cases in connection with each of the basic security services: authentication,

confidentiality, access control, integrity, and availability.

Third, one can brainstorm on the basis of a set of existing use cases. This is a far less structured way

to identify risks in a system, yet is good for identifying representative risks and for ensuring the first

two approaches did not overlook any obvious threats. Misuse cases derived in this fashion are often

written in terms of a valid use and then annotated to have malicious steps.

15.2.2: Describe misuse cases

A system will have a number of predefined roles, and a set of attackers that might reasonably target

instances of the system under development. These together should constitute the set of actors that should be

considered in misuse cases.

As with traditional use cases, you should establish which actors interact with a use case - and how they do

so - by showing a communicates-association. Also as traditionally done, one can divide use cases or actors

into packages if they become too unwieldy.

Important misuse cases should be represented visually, in typical use case format, with steps in a misuse set

off (e.g., a shaded background), particularly when the misuse is effectively an annotation of a legitimate use

case.

Those misuse cases that are not depicted visually but are still important to communicate to the user should be

documented, as should any issues not handled by the use case model.

15.2.3: Identify defense mechanisms for misuse cases

As one identifies defense mechanisms for various threats specified in a use case model, one should update

the use case model to illustrate the defense mechanism. If there is no identified mechanism at a particular

point in time, the use case should be annotated to say so.

Defense mechanisms either should map directly to a functional requirement, or, if the defense mechanism is

user-dependent, to an item in an operational security guide.

15.2.4: Evaluate results with stakeholders

Review and discuss the misuse case with stakeholders, so that they have a clear understanding of the misuse

case and agree that it is an adequate reflection of their requirements.

15.3: Threat modeling tools: [ http://vitalflux.com/list-of-threat-modeling-tools/]

Following is the list of threat modeling tools you may keep handy for threat modeling:

Microsoft Free SDL Threat Modeling Tool: Tool from Microsoft that makes threat modeling easier for

all developers by providing guidance on creating and analyzing threat models. Following diagram

displays the SDL threat modeling process:

http://www.microsoft.com/en-us/download/details.aspx?id=2955



3rd

Class

72



SDL Threat Modeling Process

Microsoft Free Threat Analysis & Modeling v2.1.2: Allows non-security subject matter experts

to enter already known information including business requirements and application

architecture which is then used to produce a feature-rich threat model.

MyAppSecurity ThreatModeler

Trike: an open source threat modeling methodology and tool: Trike is a conceptual framework

for threat modeling.

http://www.microsoft.com/en-us/download/details.aspx?id=14719

http://myappsecurity.com/threatmodeler/

http://octotrike.org/