J. Viega and G. McGraw. Building Secure Software. Addison-Wesley, 2001. Home/Search Document Not in Database Summary Related Articles Check |
This paper is cited in the following contexts:
Requirement Engineering Meets Security: A Case Study On . . . - Giorgini (2003) (Correct)
....and deployment. In 2000, Devambu and Stubblebine introduced with these words their ICSE article on security and software engineering [5] The article marked a surfacing need in the IT community: security is not just about securing protocols and communication lines, it is also about software [1, 16]. Indeed, the need of securing software is even more pressing than the need of securing communication. Almost no attack has been reported in the literature where hackers harvesting credit card numbers by snooping communication lines, whereas exploits of software security bugs are constantly among ....
.... credit card numbers by snooping communication lines, whereas exploits of software security bugs are constantly among the headlines [20] It has also clearly emerged that security concerns must be tackled from the very beginning because looking at them as an afterthought often leads to problems [1, 16]. In their ICSE article, Devambu and Stubblebine posed a challenge of integrating security concerns with requirements engineering, and in particular with UML. Part of this challenge has been answered, and indeed we have a number of proposals for UML models that incorporate security features [9, ....
[Article contains additional citation context not shown here]
G. McGraw and J. Viega. Building Secure Software. Addison Wesley Professional computing, 2001.
Testing C Programs for Buffer Overflow Vulnerabilities - Haugh (2002) (Correct)
....of that source is security critical. A bu er over ow aw in a security critical program often represents a security vulnerability. 1. 2 Common Attacks In the classic scenario, the bu er is located on the program stack, and the value written over is the return address for the current stack frame [2, 38]. The return address is changed to point back into the bu er, and when the function in which the over ow occurred returns, the program jumps to the bogus return address and begins executing the contents of the bu er. Since the contents of the bu er were determined by the attacker, she can then ....
J. Viega, G. McGraw. Building Secure Software, Addison-Wesley, Boston, 2002. 77
Towards a Model of the Costs of Security - Larochelle, Rosasco (2003) (Correct)
....limited product availability and network externalities also contribute. 1. Introduction the most secure computer in the world is one that has its disk wiped, is turned off, and is buried in a 10 foot hole filled with concrete. Of course, a machine that secure also turns out to be useless. [Viega02, 35]. As is the case in many areas, in information security there is no free lunch. The process of system design involves trade offs between numerous factors. Developers and administrators have limited resources and multiple criteria to fulfill. To an extent, security is inherently opposed to ....
John Viega and Gary McGraw, Building Secure Software, Addison-Wesley, 2002. 11
Testing C Programs for Buffer Overflow Vulnerabilities - Haugh, Bishop (2003) (Correct)
.... bounds checking when writing data into a fixed length buffer, or does the bounds checking incorrectly (for example, the check is off by one) 15, 20] In the classic scenario, the buffer is located on the program stack, and the value written over is the return address for the current stack frame [1, 23]. The return address is changed to point back into the buffer, and when the function in which the overflow occurred returns, the program jumps to the bogus return address and begins executing the contents of the buffer. Since the contents of the buffer were determined by the attacker, she can ....
J. Viega and G. McGraw. Building Secure Software. Addison-Wesley, Boston, 2002.
Teaching Software Engineering Using Lightweight Analysis - Evans (2001) (Correct)
....static analysis tools to check invariants produced by Daikon. This approach has been used with ESC Java with promising results [Nimmer01] and will be attempted with LCLint soon [Ernst01] Security Vulnerabilities Bad software is by far the most common technical cause of security vulnerabilities [MV01]. The preponderance of security problems stem from programming errors, not from flaws in algorithms or protocols. Nevertheless, security is often not part of an undergraduate curriculum, and rarely discussed in software engineering classes. Analysis tools can be used to great benefit in teaching ....
Gary McGraw and John Viega. Building Secure Software. To appear, Addison-Wesley, 2001.
The Magazine Of Usenix Sage - December Volume Number (2002) Self-citation (Gary) (Correct)
No context found.
ISBN 1882114-43-4. Gary McGraw & John Viega, Building Secure Software. Boston, MA: AddisonWesley, 2001. 528pp.
Security as a New Dimension in Embedded System Design - Kocher, Lee, McGraw.. (2004) (2 citations) Self-citation (Mcgraw) (Correct)
No context found.
J. Viega and G. McGraw, Building Secure Software (http://www.buildingsecuresoftware.com). Addison-Wesley, 2001.
Software Security: Thought leadership in information security - McGraw Self-citation (Mcgraw Software) (Correct)
No context found.
John Viega and Gary McGraw, Building Secure Software. Addison-Wesley. New York, 2001. See http://www.buildingsecuresoftware.com/ .
Security and Trust Requirements Engineering - Paolo Giorgini Fabio (Correct)
No context found.
J. Viega and G. McGraw. Building Secure Software. Addison-Wesley, 2001.
Modeling Security Requirements through Ownership.. - Giorgini.. (2005) (1 citation) (Correct)
No context found.
J. Viega and G. McGraw. Building Secure Software. Addison-Wesley, 2001.
Understanding Data Lifetime via Whole System Simulation - Jim Chow Ben (2004) (5 citations) (Correct)
No context found.
J. Viega and G. McGraw. Building Secure Software. AddisonWesley, 2002.
Software Protection and Application Security: Understanding .. - Main, van Oorschot (Correct)
No context found.
J. Viega, G. McGraw, Building Secure Software, Addison Wesley, 2001.
International Journal of Information Security manuscript No. - Will Be Inserted (Correct)
No context found.
Viega J, McGraw G (2001), Building Secure Software, Addison-Wesley, Reading, MA
A Taxonomy of Causes of Software Vulnerabilities - In Internet Software (Correct)
No context found.
John Viega and Gary McGraw. Building Secure Software. Addison-Wesley, 2002. 5
Code Inection in C and CPP: A Survey of Vulnerabilities.. - Younan, Joosen, Piessens (2004) (Correct)
No context found.
John Viega and Gary McGraw. Building Secure Software. Addison-Wesley, 2002. (Cited on page 3.)
Database encryption as an Aspect - Boström (2004) (Correct)
No context found.
John Viega, Gary McGraw. Building Secure Software. Addison Wesley. Summer, 2001.
Ostia: A Delegating Architecture for Secure System Call.. - Tal Garfinkel Ben (2003) (1 citation) (Correct)
No context found.
J. Viega and G. McGraw. Building Secure Software, pages 209--229. Addison-Wesley, 2002.
Understanding Data Lifetime via Whole System Simulation - Chow, Pfaff, Garfinkel.. (2004) (5 citations) (Correct)
No context found.
J. Viega and G. McGraw. Building Secure Software. AddisonWesley, 2002.
Bringing Security Home: A process for developing secure.. - Flechais, Sasse, Hailes (2003) (Correct)
No context found.
Viega, J. & McGraw, G. Building Secure Software. 2002. Addison-Wesley.
Trusted Software's Holy Grail - Voas (2003) (1 citation) (Correct)
No context found.
J. Viega and G. McGraw. Building Secure Software, Addison Wesley, 2001
CoBFIT: A Component-Based Framework for Intrusion Tolerance - Ramasamy, Agbaria, Sanders (Correct)
No context found.
J. Viega and G. McGraw. Building Secure Software. Addison-Wesley, 2001.
Ferret: A Host Vulnerability Checking Tool - Sharma, Martin, Anand, Cukier.. (Correct)
No context found.
J. Viega and G. McGraw, Building Secure Software, Addison-Wesley, 2002.
Online articles have much greater impact More about CiteSeer.IST Add search form to your site Submit documents Feedback
CiteSeer.IST - Copyright Penn State and NEC