Re: [SC-L] What's the next tech problem to be solved in software security?

2007-06-06 Thread Michael Silk
you've got a few questions there ... i'll answer the first one. i might copy the suggestion from someone [i can't remember who at the moment] who suggested the next step in programming in-general is more parallel programs [in order to increase speed]. this is obviously complicated and will create

Re: [SC-L] Perspectives on Code Scanning

2007-06-06 Thread Michael Silk
On 6/7/07, McGovern, James F (HTSC, IT) [EMAIL PROTECTED] wrote: I really hope that this email doesn't generate a ton of offline emails and hope that folks will talk publicly. It has been my latest thinking that the value of tools in this space are not really targeted at developers but

[SC-L] Chinese Professor Cracks Fifth Data Security Algorithm (SHA-1)

2007-03-21 Thread Michael Silk
Awesome. --- http://en.epochtimes.com/tools/printer.asp?id=50336 The Epoch Times Home Science Technology Chinese Professor Cracks Fifth Data Security Algorithm SHA-1 added to list of accomplishments Central News Agency Jan 11, 2007 Associate professor Wang

Re: [SC-L] Darkreading: compliance

2007-03-13 Thread Michael Silk
On 3/14/07, Gary McGraw [EMAIL PROTECTED] wrote: Once again i'll ask. Which vertical is the kind of company where you're seeing this awful behavior in? well, fwiw, i've noticed it in finance/investment, and the entertainment industries. but i honestly don't think the industry type makes a

Re: [SC-L] Darkreading: compliance

2007-03-12 Thread Michael Silk
On 3/13/07, Gary McGraw [EMAIL PROTECTED] wrote: hi sc-l, this month's darkreading column is about compliance. my own belief is that compliance has really helped move software security forward. in particular, sox and pci have been a boon:

Re: [SC-L] What defines an InfoSec Professional?

2007-03-08 Thread Michael Silk
On 3/9/07, McGovern, James F (HTSC, IT) [EMAIL PROTECTED] wrote: Traditionally InfoSec folks defined themselves as being knowledgable in firewalls, policies, etc. Lately, many enterprises are starting to recognize the importance of security within the software development lifecycle where even

Re: [SC-L] Dark Reading - Desktop Security - Here Comes the (Web) Fuzz - Security News Analysis

2007-02-27 Thread Michael Silk
On 2/27/07, Kenneth Van Wyk [EMAIL PROTECTED] wrote: Here's an interesting article from Dark Reading about web fuzzers. Web fuzzing seems to be gaining some traction these days as a popular means of testing web apps and web services.

Re: [SC-L] Disclosure: vulnerability pimps? or super heroes?

2007-02-27 Thread Michael Silk
On 2/28/07, Gary McGraw [EMAIL PROTECTED] wrote: Hi all, The neverending debate over disclosure continued at RSA this year with a panel featuring Chris Wysopl and others rehashing old ground. There are points on both sides, with radicals on one side (say marcus ranum) calling the disclosure

Re: [SC-L] By default, the Verifier is disabled on .Net and Java

2006-05-13 Thread Michael Silk
(Main.java:26) Java Result: 1 This error is thrown irrespective of the -verify flag. So it looks like using a classloader causes the VM to perform verification, whether or not the verifier was enabled. Michael Silk made a similar statement earlier in this thread. Would you agree? PoC code below

Re: [SC-L] By default, the Verifier is disabled on .Net and Java

2006-05-12 Thread Michael Silk
On 5/12/06, Dinis Cruz [EMAIL PROTECTED] wrote: Michael Silk wrote: What is the point of the verifier?' , 'Why use it? and 'What are the real security advantages of enabling the verifier if the code is executed in an environment with the security manager disabled?' Huh? You can find what

Re: [SC-L] By default, the Verifier is disabled on .Net and Java

2006-05-11 Thread Michael Silk
The verifier is enabled via the commandline. It is either on or off. the VM does other forms of verification though. http://java.sun.com/docs/books/vmspec/2nd-edition/html/ConstantPool.doc.html#79383 ... -- Michael On 5/11/06, Jeff Williams [EMAIL PROTECTED] wrote: Stephen de Vries wrote:

Re: [SC-L] By default, the Verifier is disabled on .Net and Java

2006-05-08 Thread Michael Silk
On 5/9/06, Dinis Cruz [EMAIL PROTECTED] wrote: Stephen de Vries wrote: Java has implemented this a bit differently, in that the byte code verifier and the security manager are independent. So you could for example, run an application with an airtight security policy (equiv to partial

Re: [Owasp-dotnet] Re: [SC-L] By default, the Verifier is disabled on .Net and Java

2006-05-05 Thread Michael Silk
Two important clarifications for Java (based on my experiments): 1) The verifier IS enabled for the classes that come with the Java platform, such as those in rt.jar. So, for example, if you create a class that tries to set System.security (the private variable that points to the

Re: [SC-L] By default, the Verifier is disabled on .Net and Java

2006-05-04 Thread Michael Silk
On 5/4/06, Dinis Cruz [EMAIL PROTECTED] wrote: Wall, Kevin wrote: Also, from the results of your test, it seems to indicate that SOME TYPE of verification is taking place, but if all you did was change a few ARBITRARY bytes in the .class file, I don't think that proves the byte code

Re: [SC-L] By default, the Verifier is disabled on .Net and Java

2006-05-03 Thread Michael Silk
Verifier in 1.5 is definately OFF by default: to confirm this do the following: 1. Create this class: == public class Foo { public static int k = 23; static { System.out.println(initially k: + k); } public static void m(){ System.out.println(m()

Re: [SC-L] Credentials for Application use

2005-05-12 Thread Michael Silk
If you are just talking about a password to access a db, the 'typical' approach (at least the approach I use) is just to store that password in the code/config file. You may like to add a layer to that by encrypting it in some config file, and requiring a 'decryption' (initialisation) of the

Re: [SC-L] Why Software Will Continue to Be Vulnerable

2005-05-03 Thread Michael Silk
On 5/2/05, Kenneth R. van Wyk [EMAIL PROTECTED] wrote: Michael Silk wrote: I honestly don't believe that the consumers will _EVER_ care, and I don't believe that should have to. At most maybe they should just need to keep an eye out for a sticker, or star-rating (government approved

Re: [SC-L] Why Software Will Continue to Be Vulnerable

2005-05-02 Thread Michael Silk
Inline.. On 5/2/05, Jeff Williams [EMAIL PROTECTED] wrote: What really mystifies me is the anlogy to fire insurance. *Everyone* keeps their fire insurance up to date, it costs money, and it protects against a very rare event that most fire insurance customers have never experienced. What

Re: [SC-L] Re: Application Insecurity --- Who is at Fault?

2005-04-14 Thread Michael Silk
I don't think that analogy quite fits :) If the 'grunts' aren't doing their job, then yes - let's blame them. Or at least help them find ways to do it better. -- Michael [Ed. Let's consider this the end of the thread, please. Unless someone wants to say something that is directly relevant to

Re: [SC-L] Re: Application Insecurity --- Who is at Fault?

2005-04-13 Thread Michael Silk
On 4/13/05, der Mouse [EMAIL PROTECTED] wrote: I would question you if you suggested to me that you always assume to _NOT_ include 'security' and only _DO_ include security if someone asks. Security is not a single thing that is included or omitted. Again, in my experience that is not

Re: [SC-L] Re: Application Insecurity --- Who is at Fault?

2005-04-11 Thread Michael Silk
Dave, On Apr 11, 2005 9:58 PM, Dave Paris [EMAIL PROTECTED] wrote: The programmer is neither the application architect nor the system engineer. In some cases he is. Either way, it doesn't matter. I'm not asking the programmer to re-design the application, I'm asking them to just program the

Re: [SC-L] Application Insecurity --- Who is at Fault?

2005-04-07 Thread Michael Silk
On Apr 7, 2005 12:43 PM, Blue Boar [EMAIL PROTECTED] wrote: Michael Silk wrote: See, you are considering 'security' as something extra again. This is not right. It is extra. It's extra time and effort. And extra testing. And extra backtracking and schedule slipping when you realize you

Re: [SC-L] Application Insecurity --- Who is at Fault?

2005-04-07 Thread Michael Silk
Dave, What you're proposing is that the ironworker should reengineer the bridge in-situ (as if he even has the authority!), causing weeks of delay, cost overruns, and possibly lead to his employer never getting a bridge contract again. That's not at all what I'm suggesting... guess my point

Re: [SC-L] Application Insecurity --- Who is at Fault?

2005-04-06 Thread Michael Silk
Quoting from the article: ''You can't really blame the developers,'' I couldn't disagree more with that ... It's completely the developers fault (and managers). 'Security' isn't something that should be thought of as an 'extra' or an 'added bonus' in an application. Typically it's just about

Re: [SC-L] Mobile phone OS security changing?

2005-04-06 Thread Michael Silk
On Apr 7, 2005 3:12 AM, Kenneth R. van Wyk [EMAIL PROTECTED] wrote: On Wednesday 06 April 2005 09:26, Michael Silk wrote: The last thing I want is my mobile phone updating itself. I imagine that sort of operation would take up battery power, and possibly cause other interruptions ... (can

Re: [SC-L] Application Insecurity --- Who is at Fault?

2005-04-06 Thread Michael Silk
- From: Michael Silk [EMAIL PROTECTED] To: Kenneth R. van Wyk [EMAIL PROTECTED] Cc: Secure Coding Mailing List SC-L@securecoding.org Sent: Wednesday, April 06, 2005 9:40 AM Subject: Re: [SC-L] Application Insecurity --- Who is at Fault? Quoting from the article: ''You can't really

Re: [SC-L] Application Insecurity --- Who is at Fault?

2005-04-06 Thread Michael Silk
] -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Michael Silk Sent: Wednesday, April 06, 2005 9:40 AM To: Kenneth R. van Wyk Cc: Secure Coding Mailing List Subject: Re: [SC-L] Application Insecurity --- Who is at Fault? Quoting from

Re: [SC-L] Application Insecurity --- Who is at Fault?

2005-04-06 Thread Michael Silk
be given upfront Agreed. -- Michael Michael Silk wrote: Quoting from the article: ''You can't really blame the developers,'' I couldn't disagree more with that ... It's completely the developers fault (and managers). 'Security' isn't something that should be thought of as an 'extra