111111
`
`1111111111111111111111111111111111111111111111111111111111111
`US007207065B2
`
`c12) United States Patent
`Chess et al.
`
`(10) Patent No.:
`(45) Date of Patent:
`
`US 7,207,065 B2
`Apr. 17, 2007
`
`(54) APPARATUS AND METHOD FOR
`DEVELOPING SECURE SOFTWARE
`
`(75)
`
`Inventors: Brian Chess, Mountain View, CA (US);
`Arthur Do, Danville, CA (US); Sean
`Fay, San Francisco, CA (US); Roger
`Thornton, San Jose, CA (US)
`
`(73) Assignee: Fortify Software, Inc., Menlo Park, CA
`(US)
`
`( *) Notice:
`
`Subject to any disclaimer, the term of this
`patent is extended or adjusted under 35
`U.S.C. 154(b) by 0 days.
`
`(21) Appl. No.: 111010,146
`
`(22) Filed:
`
`Dec. 10, 2004
`
`(65)
`
`Prior Publication Data
`
`US 2005/0273854 Al
`
`Dec. 8, 2005
`
`Related U.S. Application Data
`
`(60) Provisional application No. 60/577,066, filed on Jun.
`4, 2004.
`
`(51)
`
`Int. Cl.
`G06F 11100
`(2006.01)
`H04L 9132
`(2006.01)
`(52) U.S. Cl. ............................... 726/25; 726/3; 726/22
`(58) Field of Classification Search .................. 726/22,
`726/25
`See application file for complete search history.
`
`(56)
`
`References Cited
`
`U.S. PATENT DOCUMENTS
`
`5,440,723 A
`5,502,815 A
`200110027383 A1
`2002/0066024 A1
`
`8/1995 Arnold eta!.
`3/1996 Cozza
`10/2001 Maliszewski
`5/2002 Schmall et a!.
`
`2002/0073330 A1
`2003/0120951 A1
`2003/0159063 A1 *
`2004/0133777 A1 *
`2004/0255163 A1 *
`2004/0255277 A1
`2004/0260940 A1
`2004/0268322 A1
`2005/0010806 A1
`2005/0015752 A1
`2005/0028002 A1
`2005/0273860 A1 *
`
`6/2002 Chandnani et a!.
`6/2003 Gartside et a!.
`........ 713/200
`8/2003 Apfelbaum et a!.
`7/2004 Kiriansky eta!. .......... 713/166
`12/2004 Swimmer eta!. ........... 713/201
`12/2004 Berg et a!.
`12/2004 Berg et a!.
`12/2004 Chow et al.
`112005 Berg et a!.
`112005 Alpern et a!.
`2/2005 Christodorescu et a!.
`12/2005 Chess et al ................... 726/25
`
`OTHER PUBLICATIONS
`
`"Publication
`
`date
`
`http:/ /java. sun. com/ doc s/books/j Is/ second_ edi tion/html/ express(cid:173)
`ions.doc.html#20448 "Publication date unknown, but prior to Dec.
`10, 2004."
`http:/ /j ava.sun.com/products/ejb/docs.html
`unknown, but prior to Dec. 10, 2004."
`http:/ /java. sun. com/products/j dbc/ reference/index.html
`tion date unknown, but prior to Dec. 10, 2004."
`http:/ /j ava.sun.com/j2se/ 1.4 .2/docs/api/java/lang/reflect/package(cid:173)
`summary.html "Publication date unknown, but prior to Dec. 10,
`2004."
`http:/ /j ava.sun.com/j2se/ 1.4 .2/docs/api/java/rmi/package-summary.
`html "Publication date unknown, but prior to Dec. 10, 2004."
`* cited by examiner
`Primary Examiner-Kambiz Zand
`(74) Attorney, Agent, or Firm-Cooley Godward Kronish
`LLP
`
`"Publica(cid:173)
`
`(57)
`
`ABSTRACT
`
`A computer readable medium includes executable instruc(cid:173)
`tions to analyze program instructions for security vulner(cid:173)
`abilities. The executable instructions convert diverse pro(cid:173)
`gram instruction formats to a common format. A system
`model is derived from the common format. A static analysis
`is performed on the system model to identifY security
`vulnerabilities. Security vulnerabilities are then reported.
`
`20 Claims, 7 Drawing Sheets
`
`Common Format Generator
`Security Development Rules
`Analysis Engine
`Report Genterator
`
`Secunty Test Module
`Attack Manager Module
`Attack Database
`Security Test Rules
`Fault Injection Module
`Test Report Generator
`
`Security Monitoring Module
`
`Sensor Insertion Module
`Security Monitoring Rules
`
`FireEye - Exhibit 1017 Page 1
`
`

`
`U.S. Patent
`
`Apr. 17, 2007
`
`Sheet 1 of 7
`
`US 7,207,065 B2
`
`100\
`
`102\
`
`CPU
`
`.,
`
`·~
`
`1 12\
`
`104\
`
`I/0 Devices
`
`r1o6
`
`l
`r
`
`~
`
`.,
`
`Security Development Module
`
`110 --
`N~o;)
`
`'""'-: _.,..
`H
`108\ ,
`
`Network
`Interface
`h
`
`,,
`
`~114
`
`Interface Module
`Common Format Generator
`Security Development Rules
`Analysis Engine
`Report Genterator
`
`Security Test Module
`
`Attack Manager Module
`
`Attack Database
`Security Test Rules
`Fault Injection Module
`Test Report Generator
`
`Security Monitoring Module
`
`Sensor Insertion Module
`Security Monitoring Rules
`Monitoring Analysis Module
`Monitoring Report Generator
`
`FIG. I
`
`i---120
`i---122
`i---123
`i---124
`i---126
`
`i---116
`
`f..----128
`i---130
`i---131
`i---132
`i---134
`
`f----118
`
`i---136
`i---137
`i---138
`i---140
`
`FireEye - Exhibit 1017 Page 2
`
`

`
`U.S. Patent
`
`Apr. 17, 2007
`
`Sheet 2 of 7
`
`US 7,207,065 B2
`
`Convert source code into ~ 200
`a common format
`~ ,
`
`Create system model of
`application from common
`format
`
`~ ,
`
`202
`~
`
`204
`~
`
`Perform data flow analysis
`on system model to
`identify security vulnerabilities
`
`, ,
`Report security vulnerablilties ~ 206
`to user and related modules
`
`FIG. 2
`
`FireEye - Exhibit 1017 Page 3
`
`

`
`U.S. Patent
`
`Apr.17, 2007
`
`Sheet 3 of 7
`
`US 7,207,065 B2
`
`#2
`
`#3
`
`#4
`
`14
`
`16
`
`#5
`
`(
`
`37
`38
`
`FIG. 2A
`
`FireEye - Exhibit 1017 Page 4
`
`

`
`U.S. Patent
`
`Apr. 17, 2007
`
`Sheet 4 of 7
`
`US 7,207,065 B2
`
`302
`
`Security
`Development
`Module
`Input
`
`303
`
`Attack
`Database/
`Security Rules
`
`Identify
`Potential
`Vulnerabilities
`
`Apply
`Vulnerability
`Tests
`
`Analyze
`Performance
`
`Report
`Results
`
`FIG. 3
`
`306
`
`308
`
`310
`
`FireEye - Exhibit 1017 Page 5
`
`

`
`U.S. Patent
`
`Apr. 17, 2007
`
`Sheet 5 of 7
`
`US 7,207,065 B2
`
`Security
`Development
`Module
`Input
`
`Security Tests
`Module Input
`
`---
`
`Sensor
`Insertion
`
`~400
`
`,,
`
`Execute Code
`With Sensors
`
`,,
`
`Monitor
`Execution
`
`~406
`
`~408
`
`v--410
`
`Report
`Results
`
`FIG. 4
`
`FireEye - Exhibit 1017 Page 6
`
`

`
`r--------~----------------------------------------------l
`
`I
`
`e •
`
`•
`00
`
`138\
`
`Analysis Module
`
`... .. Global Monitoring
`,, r51o
`
`Processing Rules
`Global Monitoring
`
`512 '\
`
`Responses
`Queries and
`
`Alerts
`
`r514
`
`... r--
`
`Analysis Module
`Local Monitoring
`
`506\ 1w
`
`Rules
`
`Processing
`
`Local Monitoring
`
`508\
`
`L--------------------------------------------------------~
`
`'-516
`
`FIG. 5
`
`-.
`
`..
`
`l
`~
`I
`I
`I
`
`I
`I
`I
`I
`I
`I
`
`504_)
`
`Commands
`
`Counter-Measure
`
`Security Events
`
`502\
`
`~ ...
`
`Sensors
`Code with
`Executing
`
`500\
`
`FireEye - Exhibit 1017 Page 7
`
`

`
`U.S. Patent
`
`Apr. 17, 2007
`
`Sheet 7 of 7
`
`US 7,207,065 B2
`
`0
`0
`0
`
`r 614
`
`0
`0
`0
`
`0
`0
`0
`
`620 A
`
`620 B
`
`620 N
`
`EPRs
`
`Transceiver
`
`Transceiver
`
`Transceiver
`
`602\
`
`/614
`
`Event/EPR
`
`Event/EPR
`
`/604_A
`
`;604_B
`
`j~
`
`Transceiver
`
`Transceiver
`
`~~
`r602_A
`
`h
`
`r602_B
`
`Event
`
`Event
`
`/616
`Alert
`
`~~
`
`e_606
`
`Analysis
`Module
`
`~~
`
`r602_N
`
`Event
`
`;600_N
`
`;600_A
`
`Sensor
`
`Sensor 000
`
`Sensor
`
`FIG. 6
`
`FireEye - Exhibit 1017 Page 8
`
`

`
`1
`APPARATUS AND METHOD FOR
`DEVELOPING SECURE SOFTWARE
`
`US 7,207,065 B2
`
`This application claims priority to the U.S. Provisional
`Patent Application entitled "Apparatus and Method for
`Developing, Testing and Monitoring Secure Software", Ser.
`No. 60/577,066, filed Jun. 4, 2004. This application is
`related to the following commonly owned and concurrently
`filed patent applications: "Apparatus and Method for Devel(cid:173)
`oping, Testing and Monitoring Secure Software", U.S. Ser. 10
`No. 11/009,570, filed Dec. 10, 2004; "Apparatus and
`Method for Testing Secure Software", U.S. Ser. No. 11/009,
`474, filed Dec. 10, 2004; "Apparatus and Method for Moni(cid:173)
`toring Secure Software", U.S. Ser. No. 11/009,572, filed
`Dec. 10, 2004.
`
`BRIEF DESCRIPTION OF THE INVENTION
`
`This invention relates generally to software security.
`More particularly, this invention relates to comprehensive
`techniques for identifYing software security vulnerabilities
`during software development, testing and deployment.
`
`BACKGROUND OF THE INVENTION
`
`25
`
`2
`flaw in the outside-in premise, however, is that vulnerable
`software can be protected at all-somehow made un-vul(cid:173)
`nerable.
`Given this background, a question naturally presents
`itself: Why are network-based computer security solutions
`applied to what is clearly a software problem? One answer
`is that most information security practitioners have network
`security backgrounds and are spread thin resolving opera-
`tional security issues, leaving little time to interact with the
`core software development process. At the same time,
`application developers are rewarded for producing new
`features against tight deadlines, with little room for security
`considerations. Rarely does any one person own responsi(cid:173)
`bility for the security elements of the application itself.
`15 Conventional practice has been that development gets the
`business critical application shipped, and network operation
`teams will secure it. The dichotomy of these roles creates an
`extraordinary advantage for the attacker-they are the only
`ones truly experienced and focused on software security or
`20 more precisely business critical application insecurity.
`Experts in and around software development have
`increasingly acknowledged that something must be done
`about software security. Nevertheless, coherent and practical
`solutions have not been identified. There are a number of
`factors that make solutions difficult to identify. For example,
`software security vulnerabilities are subtle, logical errors
`that can span thousands of lines of code, making accurate
`detection with reasonable performance extremely difficult.
`30 At first glance, the technology challenges make such a
`solution appear more akin to compilers or niche develop(cid:173)
`ment tools. The large software development tools vendors,
`however, have not made security a core part of their offer(cid:173)
`ings. Their customer base is still largely focused on how to
`35 improve creation of features and functionality-and the
`vendors' internal teams caunot easily recognize a changing
`paradigm while they work to improve the feature sets of
`their single-purpose products. This is a classic innovators
`dilemma. In addition, the high volume development tool
`40 providers are not adept at delivering enterprise-like solutions
`that a risk management system requires or sustaining the
`price points needed to support such a solution. Indeed, the
`current state of development tool pricing has generally
`discouraged the security community from building devel-
`45 oper-oriented solutions.
`Apart from the downsides inherent in the development
`tool landscape, software security requires specialized exper(cid:173)
`tise in a constantly changing field. The problem is not just
`about finding technology to scan code, but includes creating
`50 and continually updating rules to detect these vulnerabilities.
`Delivering the rules requires expert knowledge of a con(cid:173)
`stantly growing body of research and real-world architec(cid:173)
`tures, frameworks, use patterns and many other factors that
`cause vulnerabilities in business critical applications. For
`55 example, every release of an operating system or library
`application program interfaces (APis) introduces new ways
`to make mistakes that lead to security vulnerabilities. Ven(cid:173)
`dors must deliver solutions that account for these cross-
`boundary, multi-platform architectures.
`Finally, it is unlikely that software security can be accom-
`plished by a single point solution. Similarly, it is unlikely
`that software security can be addressed solely at the devel(cid:173)
`oper level. Software security is largely a risk management
`problem. Addressing such a problem requires detailed infor-
`65 mation collected over time. It requires an approach that
`keeps software developers as productive as before, yet
`makes security metrics visible to management during devel-
`
`Businesses are increasingly dependent on information
`technology. Information systems are becoming increasingly
`more complex, higher-powered, inter-connected, and openly
`accessible to partners and customers over vastly distributed
`networks. The business environment has
`increasingly
`shifted from face-to-face interactions to largely anonymous
`electronic transactions. Software development itself is
`becoming more distributed through offshore development
`arrangements and intra-company collaborative computing.
`These trends strain the ability of organizations to secure and
`protect digital data from misuse or unauthorized access.
`Nearly every major business critical application deployed
`today contains vulnerabilities that can be exploited to cause
`considerable harm to the business or the assets it manages.
`These vulnerabilities can be leveraged to steal important
`information, sabotage computer systems or influence pro(cid:173)
`cessing for the profit or malicious intent of the attacker.
`For an experienced hacker or rouge insider, manipulating
`software to this end is made especially easy due to the
`variety of information and tools available on-line. An attack(cid:173)
`er's biggest challenge is simply finding the vulnerabilities in
`the context of a large business application. Compounding
`the problem, mainstream computer security solutions, such
`as firewalls, are based on the premise that exposed and
`vulnerable software can be protected by isolating it from the
`dangers of the outside world. Business requirements dictate
`that few business critical applications can be truly isolated.
`Most have numerous access points via data transfer inter(cid:173)
`faces, remote procedure calls, and internal and remote users.
`Firewalls and other network-oriented security solutions are
`not configured to block the type of access that business
`critical applications require. In fact, today's business func(cid:173)
`tions rely on this access so much that they would fail to
`operate if denied. For example, the stock market would fail 60
`to execute trades without the links from brokers to the
`exchanges, supply chains would break without information
`flowing between suppliers and producers, and telecommu(cid:173)
`nications would cease without the ability to connect cell
`phones to the computers that control the network or the
`billing systems that underlie the business. Attackers make
`use of these facts to compromise systems every day. The true
`
`FireEye - Exhibit 1017 Page 9
`
`

`
`US 7,207,065 B2
`
`30
`
`3
`opment, testing and deployment. It requires an enterprise
`software-like solution for managers and organizations.
`In view of the foregoing, it would be highly desirable to
`provide an improved technique for software security.
`
`SUMMARY OF THE INVENTION
`
`The invention includes a computer readable medium with
`executable instructions to analyze program instructions for
`security vulnerabilities. The executable instructions convert
`diverse program instruction formats to a common format. A
`system model is derived from the common format. A static
`analysis is performed on the system model to identify
`security vulnerabilities. Security vulnerabilities are then
`reported.
`The invention also includes a method of analyzing pro(cid:173)
`gram instructions for security vulnerabilities. Diverse pro(cid:173)
`gram instruction formats are converted to a common format.
`A system model is derived from the common format. A static
`analysis is performed on the system model to identify
`security vulnerabilities. Security vulnerabilities are then
`reported.
`
`BRIEF DESCRIPTION OF THE FIGURES
`
`The invention is more fully appreciated in connection
`with the following detailed description taken in conjunction
`with the accompanying drawings, in which:
`FIG. 1 illustrates an apparatus configured in accordance
`with an embodiment of the invention.
`FIG. 2 illustrates processing operations associated with an
`embodiment of a security development module of the inven(cid:173)
`tion.
`FIG. 2A illustrates data flow security operations to track
`taint propagation through an exemplary common code for(cid:173)
`mat utilized in accordance with an embodiment of the
`invention.
`FIG. 3 illustrates processing operations associated with an
`embodiment of a security test module of the invention.
`FIG. 4 illustrates processing operations associated with an
`embodiment of a security monitoring module of the inven(cid:173)
`tion.
`FIG. 5 illustrates the operation of a security monitoring
`module configured in accordance with an embodiment of the
`invention.
`FIG. 6 illustrates components of a security monitoring
`module configured in accordance with an embodiment of the
`invention.
`Like reference numerals refer to corresponding parts
`throughout the several views of the drawings.
`
`DETAILED DESCRIPTION OF THE
`INVENTION
`
`4
`ment, the executable instructions include three major mod(cid:173)
`ules: a security development module 114, a security test
`module 116, and a security monitoring module 118.
`The security development module 114 includes execut(cid:173)
`able instructions to facilitate a static analysis of software in
`order to identify security vulnerabilities inherent to the
`structure of the software. The software includes program
`instructions. As discussed below, the invention is operative
`with diverse program instruction formats. For example, the
`10 program instruction formats may be different source or
`executable code formats, different machine instruction for(cid:173)
`mats, and/or different program configuration file formats.
`The program instructions form various software applica(cid:173)
`tions. A set of software applications define a software
`15 system, which is analyzed in accordance with the invention,
`as discussed below. In one embodiment, the security devel(cid:173)
`opment module 114 is implemented with an interface mod(cid:173)
`ule 120, a common format generator 122, security develop(cid:173)
`ment rules 123, an analysis engine 124, and a report
`20 generator 126.
`The security test module 116 includes executable instruc(cid:173)
`tions to test the operation of software for security vulner(cid:173)
`abilities. Preferably, the security test module 116 relies upon
`information gathered by the security development module
`25 114 to refine its testing protocol. In one embodiment, the
`security test module 116 is implemented with an attack
`manager module 128, an attack database 130, security test
`rules 131, a fault injection module 132, and a test report
`generator 134.
`The security monitoring module 118 includes executable
`instructions to monitor the execution of software in order to
`identify security vulnerabilities. Preferably, the security
`monitoring module 118 relies upon information associated
`with the local execution of a program and the global
`35 execution of related programs to identifY security vulner(cid:173)
`abilities. In one embodiment, the security monitoring mod(cid:173)
`ule 118 is implemented with a sensor insertion module 136,
`security monitoring rules 137, a monitoring analysis module
`138, and a monitoring report generator 140.
`The configuration of the executable programs of FIG. 1 is
`exemplary. It should be appreciated that these modules may
`be combined in any manner and may otherwise be executed
`in any manner, such as across a network. Indeed, in many
`embodiments of the invention, these components are dis(cid:173)
`tributed across a network. Further, the operations performed
`by individual sub-modules may be combined in any number
`of ways.
`Now that the primary processing operations of the inven-
`50 tion have been introduced, attention turns to a more detailed
`discussion of these primary processing operations. As shown
`in FIG. 1, the security development module 114 includes an
`interface module 120. The interface module 120 includes
`executable code to handle interface operations. For example,
`55 the interface module handles interactions with the user via
`command lines, pull-down menus, IDE plug-ins and the
`like. The interface module also interacts with the other
`executable programs of the system, including the security
`test module 116 and the security monitoring module 118.
`FIG. 2 illustrates the primary processing operations asso-
`ciated with the other executable modules of the security
`development module 114. The first processing operation
`shown in FIG. 2 is to convert source or executable code into
`a common format 200. This operation may be implemented
`65 with the common format generator 122. The common format
`generator 122 converts all of the source or executable code
`files for all of the tiers of an application to be analyzed into
`
`40
`
`45
`
`FIG. 1 illustrates an apparatus 100 configured in accor(cid:173)
`dance with an embodiment of the invention. The apparatus
`100 includes a central processing unit 102 connected to a set
`of input and output devices 104 over a bus 106. By way of
`example, the input and output devices may include a key(cid:173)
`board, mouse, computer monitor, printer, and the like. Also 60
`connected to the bus 106 is a network interface 108, which
`uses standard devices to interface with a network 110, which
`may be a local area network, an intranet, the Internet, and the
`like.
`A memory 112 is also connected to the bus 106. The
`memory 112 stores a set of executable instructions to
`implement the operations of the invention. In one embodi-
`
`FireEye - Exhibit 1017 Page 10
`
`

`
`US 7,207,065 B2
`
`6
`and review over massive code bases. In addition, the global
`analysis must often be facilitated without access to the entire
`body of code.
`The present invention addresses these challenges that
`exist in the prior art. The security development module 114
`provides a new form of static analysis that is directed solely
`to software security issues. The security development mod(cid:173)
`ule 114 provides useful information that can be immediately
`utilized to improve software security. In addition, it provides
`10 useful information that is exploited during testing and moni(cid:173)
`toring phases.
`These operations are more fully appreciated in connection
`with an example. The following example illustrates the steps
`carried out by the security development module for a simple
`15 2-tier application. The following example is complete in that
`it provides sufficient input to identifY code vulnerabilities.
`The example is incomplete in the sense that additional
`standard tools, support logic, and configuration files are
`required to actually run the application. These additional
`20 elements are standard in the art and therefore are not subject
`to further discussion.
`The sample application consists of a Java servlet and a
`PLISQL package. The purpose of the application is to
`display an account balance to a user. The application works
`as follows. The Java servlet accepts an HTTP POST request
`that contains a parameter named "acct". This is the type of
`HTTP request typically generated by a web browser when a
`user fills out and submits a form on a web page. The "acct"
`parameter might be set, for example, by the user selecting an
`account name from a drop-down list. The servlet passes the
`value of the "acct" parameter to a database query. The query
`invokes a stored procedure in the database named "ACCT(cid:173)
`.get_balance". The stored procedure uses the parameter
`passed from the servlet in order to construct an SQL query.
`The
`query
`examines
`a
`database
`table
`named
`"ACCOUNTS". It returns the value in the "balance" column
`for the row matching the account name that is passed in. The
`stored procedure returns the balance value to the servlet, and
`the servlet in turn returns the balance value to the user.
`A malicious user can exploit vulnerability in the applica(cid:173)
`tion in order to see account balances that they are not
`authorized to see. The vulnerability is simple: the applica(cid:173)
`tion never checks to see whether the user has permission to
`see the balance of the account number that they have
`requested. This type of vulnerability is common in poorly
`written web-based applications. The problem can be viewed
`in terms of data flow: the "acct" value provided by the user
`flows unchecked into the SQL query in the database. This
`class of vulnerabilities is known as "SQL injection" because
`a malicious user can "inject" information of their choosing
`into a SQL query.
`The following is exemplary Java code for an account
`balance application:
`
`5
`a common format. The example common format disclosed
`herein is called the Normalized Syntax Tree (NST) format.
`An application system model is then derived from the
`common format 202. The common format generator 122
`may perform this operation as well. In particular, the execut(cid:173)
`able code is used to create a uniform model of the applica(cid:173)
`tion from the NST files.
`A data flow analysis is then performed on the system
`model to identifY security vulnerabilities 204. The analysis
`engine 124 may be used to implement this operation. The
`analysis engine 124 identifies possible execution paths
`through the program where user input can reach a dangerous
`function or construct. The analysis engine 124 invokes
`security development rules 123. Typically, the security
`development module 114 is deployed with a set of security
`development rules 123. These rules may be updated on a
`subscription basis from a remote computer connected to
`network 110. In addition to these supplied rules, a user may
`tailor specific security development rules for a particular
`application. The analysis engine 124 is a separate compu(cid:173)
`tational kernel and therefore it can be used with a diverse set
`of standard and customized security development rules 123.
`The security vulnerabilities identified by the analysis
`engine 124 are reported to the user and related modules 206.
`The report generator 126 may be used to implement this 25
`operation.
`The security development module 114 performs a form of
`semantic analysis across multiple tiers and languages to find
`security vulnerabilities, such as stack buffers, tainted vari(cid:173)
`ables, SQL injection and custom-defined security flaws. The 30
`tiers range from the operating system to the database,
`application server to user interface, in applications that span
`multiple languages, including Java, CIC++, HTML, JSP and
`PLISQL. The invention's analysis of diverse program
`instruction formats and systems that include multiple soft- 35
`ware applications is a significant advance over prior art
`systems.
`The security development module 114 of the invention
`may be integrated into commercially available integrated
`development environments, thus investigating warnings and 40
`removing security errors becomes a natural part of the
`edit-compile-debug software development process.
`As shown in FIG. 1, the security development module 114
`may be implemented with an analysis engine 124. The
`analysis engine 124 preferably implements a static analysis. 45
`Static analysis is a technique for analyzing software without
`executing the software. Static analysis has historically suf(cid:173)
`fered from high complexity. In particular, static analysis has
`gained a reputation for producing a high volume of suspect
`or hard to interpret results when applied to real world 50
`software.
`There are a number of challenges associated with using
`static analysis in software security operations. First, both
`global dataflow and control flow static analysis techniques
`must be used to provide accuracy. Second, the myriad 55
`languages and frameworks create special cases that must be
`handled. Third, security analysis must be extensible to cover
`the large set of application-specific vulnerabilities. Fourth,
`security analysis requires the study of attacks to define the
`semantic representation of particular vulnerability classes
`and the studies must be kept up-to-date since these attacks
`change over time. Finally, any analysis must be constrained
`by realistic commercial product requirements. The two most
`difficult requirements to satisfY in a commercial setting are
`scalability and code access. With respect to scalability, the 65
`analysis must perform with extremely low overhead at the
`developer's desktop, yet perform well in a full-scale audit
`
`60
`
`import java.sql. *;
`import javax.servlet.http. *;
`class AccountView extends HttpServlet {
`private Connection connection;
`public void doPost(HttpServletRequest request,
`HttpServletResponse response) {
`String acctNurnber ~ request.getParameter("acct");
`CallableStatement strnt ~ null;
`try{
`strnt ~
`connection.prepareCall("begin ACCT.get_balance(?, ?); end;");
`
`FireEye - Exhibit 1017 Page 11
`
`

`
`US 7,207,065 B2
`
`8
`translate the language into an executable form. Humans do
`not write the NST format, so it does not supply the niceties
`and shortcuts that are usually provided for programmers.
`Because the NST format is created from a number of
`different high-level languages, it targets the lowest common
`denominator between the languages. Of course, it must
`provide enough expressiveness to capture the meaning of all
`of the constructs in all of the languages. Compiler research(cid:173)
`ers have defined well-accepted methods for building pro-
`10 gram models. For example, see chapters 3, 4, and 8 of Aho,
`eta!., Compilers, Principles, Techniques and Tools, Pearson
`Higher Education (1985).
`Translation from a high-level language into the NST
`format is governed by a set of translation rules that are
`15 specific to the high-level language being translated. For
`example, some of the rules controlling the translation from
`Java to NST are:
`NST does not include a construct like Java's import
`statement. Java import statements have no explicit
`representation in the NST.
`Java does not require programmers to fully qualify vari(cid:173)
`able, class, and method names unless a name is poten(cid:173)
`tially ambiguous. NST requires all names to be fully
`qualified so that there is no need to check for ambiguity.
`When a name is translated from Java to NST, it is
`translated into a fully qualified form. Type and method
`resolution in Java is achieved by following the rules
`and instructions set forth in the Java Language Speci(cid:173)
`fication (section 15.12, http://java.sun.com/docs/books/
`jls/second_editionlhtml/expressions.doc.html#20448).
`In Java, all objects are referenced through pointers.
`Because there is only one way to reference an object,
`no pointer notation is necessary in Java. Because NST
`is used to represent languages like C and C++ where
`objects may be referenced directly or through pointers,
`all Java object references are translated to include
`explicit pointer reference notation in NST.
`In Java, a member function can operate on its object using
`the keyword "this". NST has no "this" keyword.
`Instead, the object associated with a member function
`is explicitly represented as the first argument to the
`function.
`The following text describes the NST syntax using gram(cid:173)
`mar-like constructs. The following conventions are used:
`
`20
`
`25
`
`30
`
`35
`
`40
`
`45
`
`7
`
`-continued
`
`I I Bind parameter types
`strnt.setString(l, acctNumber); II Bind 1st parameter
`strnt.registerOutParameter(2, Types.INTEGER); II 2nd is result
`I I Execute tbe callable statement
`strnt.execute( );
`int balance~ strnt.getlnt(2); II get result
`response.getWriter( ).write("Account balance: "+ balance);
`} catch(SQLException ex) { II Trap SQL Errors
`response.getWriter( ).write("Error: "+ ex.toString( ));
`} finally {
`try{
`if(strnt !~ null) {
`strnt.close( ); II close tbe statement
`
`}
`} catch(SQLException ex) {
`}
`
`Relying upon the same example, the following is PLISQL
`code for the Account Balance application:
`
`CREATE OR REPLACE PACKAGE ACCOUNT IS
`TYPE CURSORTYPE IS REF CURSOR;
`FUNCTION get_balance(
`NAME VARCHAR2
`
`RETURN CURSORTYPE;
`
`END;
`I
`-- Package body TEST
`CREATE OR REPLACE PACKAGE BODY TEST IS
`FUNCTION get_balance(
`NAME VARCHAR2
`) RETURN CURSORTYPE IS
`CURSORRET CURSORTYPE;
`Nl VARCHAR2;
`BEGIN
`Nl:~NAME;
`OPEN CURSORRET FOR
`SELECT
`balance
`FROM
`ACCOUNTS
`WHERE
`(ACT_NUMBER ~ Nl);
`RETURN CURSORRET;
`END;
`END;
`I
`commit;
`show errors;
`exit;
`************************************************************
`
`As previously indicated, the initial operation performed
`by the security development module is to convert all of the
`source or executable code files for all of the tiers of the 55
`application into a common format, called the Normalized
`Syntax Tree (NST) format.
`This step involves parsing each source or executable code
`file according to the language it is written in and then
`translating the parsed information into the NST format. This
`step closely resembles the first phase carried out by a
`modern high-level language compiler (such as the Gnu C
`compiler, gee) where the compiler creates a high-level
`intermediate language from a source or executable file.
`High-levellanguages are designed for balance between the 65
`freedom and expressiveness given to the programmer and
`rules and constraints necessary for a compiler to e