[SC-L] Reusable Security for Segmented Data Domains
Article which may be of interest to the J2EE crowd: http://www.growingbusinesssolutions.com/Reusable-Security-for- Segmented-Data-Domains.pdf According to John C. Dale, MS MIS, president of Growing Business Solutions, for firms providing software development outsourcing services, the practice of software reuse can reduce overhead and increase margins. Currently, an alarming number of enterprise software development projects are over budget, delivered late, or both. As software development organizations mature, so too should their ability to deliver increasingly complex software solutions on time and on budget. One strategy for achieving this is to identify opportunities for software reuse. In traditional manufacturing nomenclature, this process would be expressed as manufacturing efficiency or economy of scale. In this article, Dale discusses one way in which open source J2EE Security Realms can be used to facilitate code reuse - and thus manufacturing efficiency - into the enterprise software manufacturing process. Subsequently, enterprise software development firms who employ this methodology should expect to deliver software with greater efficiency and predictability at a lower cost. -- Stephen de Vries Corsaire Ltd E-mail: [EMAIL PROTECTED] Tel:+44 1483 226014 Fax:+44 1483 226068 Web:http://www.corsaire.com ___ 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] Comparing Scanning Tools
| Date: Mon, 5 Jun 2006 16:50:17 -0400 | From: McGovern, James F (HTSC, IT) [EMAIL PROTECTED] | To: sc-l@securecoding.org | Subject: [SC-L] Comparing Scanning Tools | | The industry analyst take on tools tends to be slightly different than | software practitioners at times. Curious if anyone has looked at Fortify and | has formed any positive / negative / neutral opinions on this tool and | others... We evaluated a couple of static code scanning tools internally. The following is an extract from an analysis I did. I've deliberately omitted comparisons - you want to know about Fortify, not how it compares to other products (which raises a whole bunch of other issues), and included the text below. Standard disclaimers: This is not EMC's position, it's my personal take. Caveats: This analysis is based on a 3-hour vendor presentation. The presenter may have made mistakes, and I certainly don't claim that my recall of what he said is error-free. A later discussion with others familiar with Fortify indicated that the experience we had is typical, but is not necessarily the right way to evaluate the tool. Effective use of Fortify requires building a set of rules appropriate to a particular environment, method of working, constraints, etc., etc. This takes significant time (6 months to a year) and effort, but it was claimed that once you've put in the effort, Fortify is a very good security scanner. I am not in a position to evaluate that claim myself. BTW, one thing not called out below is that Fortify can be quite slow. Our experience in testing was that a Fortify scan took about twice as long as a C++ compile/link cycle, unless you add data flow analysis - in which case the time is much, much larger. The brief summary: In my personal view, Fortify is a worthwhile tool, but it would not be my first choice. (Given the opportunity to choose two tools, it would probably be my second.) Others involved in the evaluation reached the opposite conclusion, and rated Fortify first. -- Jerry Fortify Fortify is aimed as a tool for use in a security audit. It is deliberately biased in the direction of flagging all potential security issues. It provides two kinds of analysis - what they call semantic and data flow. Neither use of terminology is consistent with industry practice. Their semantic analysis is better described as a syntactic analysis: It looks at surface features of the program (use of certain calls, for example). It mainly ignores context. Fortify's own representative describe this analysis as a super grep. This analysis is driven by a large database of rules, which can be extended. (In industry practice, a semantic analysis would look deeply at the meaning of the program.) Data flow analysis is better called taint analysis. It traces all data from external sources to find code that might incorrectly rely on it. When run on our code, semantic analysis reports about 3000 problems. We looked closely at quite a number of them, and with a single exception (where the code was so complex that no one could be sure), they were false positives. For a security audit, that's probably OK. The problem is: What does one do with the false positives? If this is an isolated audit, the answer is - ignore them. But in practice code is always changing, so you'll have to audit it again. How do you avoid dealing with the same false positives every time? A look at the problems showed that in many if not most of the cases we looked at, there was no practical way to change the code to stop the complaints. You can permanently suppress individual complaints, but doing so appears to be very hazardous: The suppression is based on the line on which the problem was found. It could well be that this is a false positive because of the surrounding context - and that context might change. For example, if a line has an array reference a[i] that is safe because we can prove based on a test 10 lines earlier that i is in range - something that Fortify itself cannot do, since it does no value flow analysis - then we might suppress the warning. But a later revision to the code could eliminate the test, and we apparently would not receive a warning. The data flow analysis gives more useful results. While the vendor was here, we only had data flow analysis for a very small subset of the code: Producing this is an extremely long process (days of CPU time). Again, there were many false positives, though I would consider almost all of them to be legitimate, in the sense that the program could not possibly have known certain things about our environment that would be needed to eliminate the warning. However, in some cases, the messages were hard to understand: There was insufficient information in the result to figure out just why the program had reached the conclusion it had. Based on what the vendor told us, effective use of the data flow analysis
Re: [SC-L] Where are developers who know how to develop secure so ftware?
On Mon, 5 Jun 2006, David A. Wheeler wrote: | ... One reason is that people can get degrees in | Computer Security or Software Engineering without knowing how to | develop software that receives hostile data. Even the | Software Engineering Body of Knowledge essentially | omits security issues (a supplement is being developed, | thankfully, though it's not REQUIRED) | | If you have connections with your local university, try to talk | them into increasing the amount of education they provide in | developing secure software (where software development is done). | I give away a book on this topic, as part of my effort to get the | information disseminated Keep in mind that you can run into a fundamental conflict about what a university education is supposed to be about. At least where computer science departments are part of the liberal arts school, their fundamental view is that they are there to teach concepts, not to train people for work. The view is that, if you want someone who knows the basics of today's technologies, hire a graduate of a vocational school. Universities produce people who know how to think about technology and can learn the details of any particular technology when they need to. University programming assignments focus on the ideas, not on the trivial minutia of validating input, for example. A university cryptography course will likely be heavy on theory, light on how to safely apply cryptographic primitives. Any secure computing courses at universities are likely to focus on what someone identifies as broad principles, not on how to avoid buffer overflows in C - much less on how to restructure existing horrible C code so that you can eliminate its buffer overflows. (When I ask the typical university-trained CS major How do you recognize that a class has been designed well? about the only answer I am likely to get is that the member fields are all private and accessed through getters and setters. Sigh.) I don't want to get into a debate about the validity of this approach, but recognize that it's there and it's not going away. I would also be very careful about any sentence that starts you can get a degree without knowing X, because you'll be astounded to learn just what you can substitute for X. For example, very few CS graduates have any understanding of even the most fundamental facts about floating point arithmetic. (Ask them how many times a loop that starts an FP value at 0.0 and adds 0.1 to it until the result equal 1.0 will execute.) When I interview new college graduates, on almost all subjects, I assume that, if they got a good college education, they understand basic principles and will be able to use them to learn specifics. But on the real practice of software development, what they haven't learned through co-op programs or other work experience, I'll have to train them on. (It's also my view that design, architecture, non-trivial secure coding, and so on cannot be taught in the way that sciences are taught, by someone lecturing from the front of the room. They need to be taught as art or writing is taught - by example and by practice and critique. This is something university CS departments are rarely set up to do.) -- Jerry ___ 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] Comparing Scanning Tools
Thanks for the response. One of the things that I have been struggling to understand is not the importance of using such a tool as I believe they provide value but more of the fact that these tools may not be financial sustainable. Many large enterprises nowadays outsource development to third parties. Likewise, the mindset in terms of budgeting tends to eschew per developer seat tool purchases. Nowadays, it is rare to find an enterprise not using free tools such as Eclipse and not paying for IDEs I have yet to find a large enterprise that has made a significant investment in such tools. I wonder if budgets and the tools themselves are really causing more harm than helping in that enterprises will now think about trading off such tools vs the expense they cost. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 07, 2006 4:34 PM To: McGovern, James F (HTSC, IT) Cc: sc-l@securecoding.org Subject: Re: [SC-L] Comparing Scanning Tools | Date: Mon, 5 Jun 2006 16:50:17 -0400 | From: McGovern, James F (HTSC, IT) [EMAIL PROTECTED] | To: sc-l@securecoding.org | Subject: [SC-L] Comparing Scanning Tools | | The industry analyst take on tools tends to be slightly different than | software practitioners at times. Curious if anyone has looked at Fortify and | has formed any positive / negative / neutral opinions on this tool and | others... We evaluated a couple of static code scanning tools internally. The following is an extract from an analysis I did. I've deliberately omitted comparisons - you want to know about Fortify, not how it compares to other products (which raises a whole bunch of other issues), and included the text below. Standard disclaimers: This is not EMC's position, it's my personal take. Caveats: This analysis is based on a 3-hour vendor presentation. The presenter may have made mistakes, and I certainly don't claim that my recall of what he said is error-free. A later discussion with others familiar with Fortify indicated that the experience we had is typical, but is not necessarily the right way to evaluate the tool. Effective use of Fortify requires building a set of rules appropriate to a particular environment, method of working, constraints, etc., etc. This takes significant time (6 months to a year) and effort, but it was claimed that once you've put in the effort, Fortify is a very good security scanner. I am not in a position to evaluate that claim myself. BTW, one thing not called out below is that Fortify can be quite slow. Our experience in testing was that a Fortify scan took about twice as long as a C++ compile/link cycle, unless you add data flow analysis - in which case the time is much, much larger. The brief summary: In my personal view, Fortify is a worthwhile tool, but it would not be my first choice. (Given the opportunity to choose two tools, it would probably be my second.) Others involved in the evaluation reached the opposite conclusion, and rated Fortify first. -- Jerry Fortify * This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies. * ___ 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