Re: [SC-L] [External] Re: SearchSecurity: Dynamism
Reference monitors were a lovely concept, largely invented for multilevel security kernels and trusted computing bases, but are almost nonexistent in that context. Yes, they'd be lovely to have, but even the NSA folks seem to have abandoned them... ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. Follow KRvW Associates on Twitter at: http://twitter.com/KRvW_Associates ___
Re: [SC-L] SearchSecurity: Badware versus malware
The differences are marginal. > What's worse, bad software or malicious software? ... My book has a pervasive theme: Many things that could happen accidentally could be triggered intentionally. Many things that happen intentionally could be triggered accidentally. Trying to reduce one without the other may be foolhardy in most realistic threat models. ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. Follow KRvW Associates on Twitter at: http://twitter.com/KRvW_Associates ___
Re: [SC-L] What do you like better Web penetration testing or static code analysis?
Matt Parsons wrote: > What do you like doing better as application security professionals, web > penetration testing or static code analysis? McGovern, James F. (P+C Technology) wrote: > Should a security professional have a preference when both have > different value propositions? While there is overlap, a static analysis > tool can find things that pen testing tools cannot. Likewise, a pen test > can report on secure applications deployed insecurely which is not > visible to static analysis. > > So, the best answer is I prefer both... Both is better than either one by itself, but I think Gary McGraw would resonate with my seemingly contrary answer: BOTH penetration testing AND static code analysis are still looking at the WRONG END of the horse AFTER it has left the DEVELOPMENT BARN. Gary and I and many others have for a very long time been advocated security architectures and development practices that greatly enhance INHERENT TRUSTWORTHINESS, long before anyone has to even think about penetration testing and static code analysis. This discussion is somewhat akin to arguments about who has the best malware detection. If system developers (past-Multics) had paid any attention to system architectures and sound system development practices, viruses and worms would be mostly a nonproblem! Please pardon my soapbox. The past survives. The archives have lives, not knives. High fives! (I strive to thrive with jive.) PGN ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. Follow KRvW Associates on Twitter at: http://twitter.com/KRvW_Associates ___
Re: [SC-L] has any one completed a python security code review`
And don't forget the entire run-time environment in which the python code runs. ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. Follow KRvW Associates on Twitter at: http://twitter.com/KRvW_Associates ___
Re: [SC-L] has any one completed a python security code review`
You should look at Ka-Ping Yee's PhD thesis: http://pvote.org and the Pvote Software Review Assurance Document, Apr 3 2007. Google finds it quickly. ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. Follow KRvW Associates on Twitter at: http://twitter.com/KRvW_Associates ___
Re: [SC-L] 2010 bug hits millions of Germans | World news | The Guardian
... and of course Multics solved the Y2K problem in 1965, deferring the overflow for many additional decades. ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. ___
Re: [SC-L] Inherently Secure Code?
I don't much like INHERENTLY SECURE CODE. Software components by themselves are not secure. Security (and trustworthiness that encompasses security, reliability, survivability, etc.) is an emergent property of the entire system or enterprise. To say that a component is secure is rather fatuous. See my DARPA report on composable trustworthy architectures for starters. http://www.csl.sri.com/neumann/chats4.pdf or .html ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. ___
Re: [SC-L] What is the size of this list?
Let me amplify what Matt Bishop has said. I tend to deal with TRUSTWORTHINESS, which encompasses security, reliability, survivability, human safety, and anything else that you have to trust whether you like it or not. Security is only one aspect of it. Long ago Butler Lampson wrote a paper pointing out that if it is not secure, it won't be reliable, and if it is not reliable, it is may not be secure. That was applied to access controls in hardware, but it is equally applied to SYSTEMS. Also, all of those trustworthiness properties tend to be emergent properties of the entire system/enterprise/whatever. Beware of folks who tell you their crypto algorithm (for example) is 100% secure, and ignore that fact that if it badly implemented or the keys are stored in an unsecure operating system, then all bets are off and 100% secure becomes 0% secure. end of soapbox, which some of you have heard from me before. Peter ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. ___
Re: [SC-L] Unclassified NSA document on .NET 2.0 Framework Security
And don't forget the Paul Karger paper from Oakland, which applies access
controls to executables and effectively provides implementations for
Saltzer-Schroeder's least privilege and more:
@InProceedings{Karger87,
Key="Karger", Author="P.A. Karger",
Title="Limiting the Damage Potential of Discretionary {T}rojan Horses",
BookTitle="Proceedings of the 1987 Symposium on Security and Privacy",
Organization="IEEE Computer Society",
Address="Oakland, California", Year="1987", Month="April", pages="32--37"}
___
Secure Coding mailing list (SC-L) SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php
SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.
___
Re: [SC-L] COBOL Exploits
Searching through http://www.csl.sri.com/neumann/illustrative.html gives these COBOL-related RISKS items. The initial character descriptors are defined there. In the citations, * R relates to RISKS (archives at risks.org) * S relates to SIGSOFT Software Engineering Notes (archives at www.sigsoft.org/SEN/ although more recent items also in RISKS) Vf West Drayton ATC system bug found in 2-yr-old COBOL code (S 16 3, R 11 30) \$fe IRS COBOL reprogramming delays; interest paid on over 1,150,000 refunds (S 10 3:12) S[H?] Election frauds, lawsuits, spaghetti code, same memory locations used for multiple races simultaneously, undocumented GOTOs, COBOL ALTER verb allowing self-modifying code, calls to undocumented/unknown subroutines, bypassable audit trails (S 11 3); Report from the Computerized Voting Symposium, August 1986 (S 11 5) Sie Data transfer Excel-COBOL loses voter data in 2003 Greenville Mississippi election (R 22 95) \$hi Man gets \$218 trillion phone bill (R 24 24); COBOL program? (R 24 27,29,30,33) f Discussion of date and century roll-over problems: Fujitsu SRS-1050 ISDN display phones fail on two-digit month (10); 1401 one-character year field; COBOL improvements; IBM 360 (S 20 2:13) [See Fred Ballard and Walt Murray (R 16 70 ff).] [Lots of stuff is relevant on COBOL's two-character year field and the entire Y2K saga.] ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. ___
Re: [SC-L] How can we stop the spreading insecure coding examples at training classes, etc.?
> But my question is, is that enough? Of course not. It's nowhere near enough. Of course, there is NEVER "ENOUGH" in this business. But what you are suggesting is still very far from what might be thought of as enough under the circumstances. PGN ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php
Re: [SC-L] "Bumper sticker" definition of secure software
Gary, If you think security is a funny topic, try this one: http://haha.nu/funny/funny-math/ ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php
Re: [SC-L] "Bumper sticker" definition of secure software
You suggest: Secure software is software that remains dependable despite efforts to compromise its dependability. You need a bigger-picture view that encompasses trustworthiness and assurance. "Dependable systems are systems that remain dependable despite would-be compromises to their dependability." "Trustworthy systems are systems that are worthy of being trusted to satisfy their requirements (for security, reliability, survivability, safety, or whatever)." Security is generally too narrow by itself, because a system that is not reliable is not likely to be secure, especially when in unreliability mode! The principle of Keep It Simple is inherently unworkable with respect to security. Security is inherently complex. Trustworthiness is broader and even more complex. But if you don't think about trustworthiness more broadly, what you get is not likely to be very secure. Forget the bumper sticker approach. ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php
Re: [SC-L] Where are developers who know how to develop secure software?
I'll echo that from David. Most of you by now must have heard my experience interviewing a PhD from one of the supposedly TOP U.S. CS departments (albeit perhaps 12 years ago, before the department made a radical step forward). PGN: What does software engineering mean to you? ANS: [after long headscratching pause:] Oh, that's putting comments in the code, isn't it? ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php
Re: [SC-L] Hiring folks that are familar with SC practices
Nice discussion. It arose years ago when software development managers typically had NO experience in software development, but were thought to be good managers. Many disasters ensued. The other side of the coin is that good developers are often TERRIBLE managers. I once wrote Psychosocial Implications of Computer Software Development and Use: Zen and the Art of Computing in Theory and Practice of Software Technolgoy D. Ferrari, M. Bolognani, and J. Goguen (editors), North-Holland, 1983, pages 221-232. An earlier version appeared in Software Engineering Notes, and Will Tracz may even have that online by now. The bottom line is that you need people with well developed and coordinated LEFT- and RIGHT-brained abilities innately. Interviewing someone to be a system-oriented developer is very difficult unless the interviewer has deep knowledge of system-oriented development. Read my DARPA CHATS report on Principled Assuredly Trustworthy Composable Architectures. Your interviewers should have read and understood the essence of that report before being trusted to select good applicants. http://www.csl.sri.com/neumann/chats4.html or pdf or ps Good luck! P ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php
Re: [SC-L] Managed Code and Runtime Environments - Another layer of added security?
Der Mouse is barking up the right rathole. *** BEGIN SOAPBOX *** Having cut my security eye-teeth in Multics from 1965 to 1969, I am continually drawn back into discussions of what Multics did right that has been systematically (!) ignored by almost all subsequent operating systems. For the younger folks among the SC-L audience, let me mention a few of the architectural strengths. There were no buffer overflows in the stack, because anything out of the stack frame was not executable. The ring-structured domain architecture and file system access controls permitted straightforward sandboxing. Dynamic linking and revocation were fundamental. Segmentation and paging enabled layers of virtual machines and protected virtual memory. The I/O system had virtual stream names, virtual I/O, and common device-driver software where appropriate, coupled with separate hardware for the input-output controller (GIOC). The programming language was the stark EPL subset of PL/I and the corresponding McIlroy-Morris EPL compiler, which seems to have avoided some of the characteristic programming errors that are still common today. No software was written until there was an approved specification, with well defined interfaces and exception conditions that were explicitly characterized in EPL. And so on into a visionary sense of a future that has been largely lost for may perceived reasons, some of which are bogus, some of which are just seriously short-sighted. *** END SOAPBOX *** I'm sure this message may generate all sorts of Ifs and Ands and Buts. But the Butt we are kicking is our own. Cheers! PGN ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php
Re: [SC-L] Secured Coding
> I truly believe this as no matter how secured we make our programs there > will always be someone to figure how to break it. Don't forget the INSIDERS (and the outsiders who can become insiders, such as ex-employees who don't even have to work to figure out how to break it)... This is especially true of the election process, where everything every step is a weak link -- from registration to ballot-face preparation to voter authentication (if any) to voting to counting to recounting, with lots of deep insiders and relative insiders.
Re: [SC-L] Top security papers
Matt, You will find lots of references that might appeal to your needs in an emerging DARPA report on my web site: http://www.csl.sri.com/neumann/chats4.pdf There's an appendix by Virgil Gligor that might be very helpful to you, which does not yet appear in the html (but will as soon as I move the .eps files to .gif...) But start with the principles, e.g., Saltzer and Schroeder 1975 And don't try to look at security as an isolated problem -- it is an overall system problem, and there are lots of papers on software decomposition, composability, modularity, etc. that are fundamental to security. You might also try Matt Bishop's book, with lots of references. PGN
Re: [SC-L] ACM Queue article and security education
Gee, Some of us have been saying that for 40 years.
Re: [SC-L] Change of position
Security is an end-to-end problem. As I have said before, but not here, some folks like to talk about Strength in Depth, whereas what we have is really Weakness in Depth. There are vulnerabilities everywhere. Gary is indeed quite correct, even on April Fool's Day. If the underlying computer infrastructures are not secure AND reliable, anything you build on top of them is suspect. Don't forget denials of service, which are particularly nasty and most often ignored.
Re: [SC-L] ACL (access control lists) generic design questions
William, I'll be very interested in your extensible ACL-style authorization.
If you are serious about generalizing the ACL interpretations, you might
think back not just to Multics (with directories and files having different
interpretations of the ACL protection bits), but also to our Provably Secure
Operating System (PSOS), in which each capability had an associated type and
where the capabilities for each type had their own type-specific
interpretation of the protection bits. PGN
@inProceedings{DaleyNeumann,
Author="R.C. Daley and P.G. Neumann",
Title="A General-Purpose File System for Secondary Storage",
Booktitle="{AFIPS} Conference Proceedings, Fall Joint Computer Conference",
Publisher="Spartan Books", Year="1965", Month="November", Pages="213--229"}
The 1973-1980 work on PSOS is summarized more recently in "PSOS Revisited":
@InProceedings{NeumannFeiertag03,
Author="P.G. Neumann and R.J. Feiertag",
Title="{PSOS} Revisited",
BookTitle="Proceedings of the 19th Annual Computer Security Applications
Conference (ACSAC 2003), Classic Papers section",
Organization="IEEE Computer Society",
Address="Las Vegas, Nevada", Year="2003", Month="December", pages="208--216",
NOTE="http://www.csl.sri.com/neumann/psos03.pdf.";
}
