Re: [SC-L] Perspectives on Code Scanning

On 6/8/07, Gunnar Peterson <[EMAIL PROTECTED]> wrote: > > and that's the problem. the accountability for insecure coding should > > reside with the developers. it's their fault [mostly]. > > I find it fascinating that an industry like security, that has delivered a > grand total of TWO working mech

Re: [SC-L] Perspectives on Code Scanning

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 bu

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

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

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

Awesome. --- 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 Wan

Re: [SC-L] Darkreading: compliance

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

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: http://www.darkreading.com/document.asp?doc_id=1191

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

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] Disclosure: vulnerability pimps? or super heroes?

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] Dark Reading - Desktop Security - Here Comes the (Web) Fuzz - Security News Analysis

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. > > http://www.darkreading.com/document.asp?doc_id=118

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

On 5/14/06, Dinis Cruz <[EMAIL PROTECTED]> wrote: Kevin is correct, a type confusion attack will allow the bypass of the security manager simply because via a type confusion attack you will be able to change what the security manager is 'seeing' In both .Net and Java, the sandboxes logic (CAS a

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

ev/classloader/myclass/ somepackage/MyData.class Loading class: /Users/stephen/data/dev/classloader/myclass/java/lang/ System.class Exception in thread "main" java.lang.IllegalAccessError: tried to access method somepackage.MyData.getName()Ljava/lang/String; from class somepackage.MyTest

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

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 disa

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

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 wro

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

On 5/9/06, Dinis Cruz <[EMAIL PROTECTED]> wrote: Jeff Williams wrote: > > But Dinis is right. There is a real problem with verification, as > demonstrated in the message below. This is a clear violation of the > Java VM Spec, yet my messages to the team at Sun developing the new > verifier have b

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

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 t

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

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 SecurityManag

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

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 ve

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

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

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 'serve

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

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

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

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 > > experienc

Re: [SC-L] Java keystore password storage

As a hash function with 'security' of 2 ** 80, it is completely broken. The security is reduced to 2 ** 69. Even though it's still alot of operations, the function is definately broken as it's actual security is less then specified (less then that required for a 'birthday attack'). -- Michael On

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

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 sof

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

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 exper

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

On 4/12/05, der Mouse <[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 d

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

Joel On Apr 12, 2005 12:45 AM, Joel Kamentz <[EMAIL PROTECTED]> wrote: > Re: bridges and stuff. > > Let's use an example someone else already brought up -- cross site scripting. > How many people > feel that, before it was ever known or had ever occurred the first time, good > programming > pra

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

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] Re: Application Insecurity --- Who is at Fault?

Ed, But even your signature suggests we already have an environment like that. Clearly you have become certfied, and most job ads I view require some form of certification. Certification isn't missing from the Programming profession - there is heaps of it. So what _is_ missing? We can assume

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

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 poi

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

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 >

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

n't want to be micromanaging all these concepts (but we are - CIO's...) they should be the sole responsibility of the programmer to get right. > The later takes far more time to impliment than is > given in many environments. The former requires sufficient > specificatio

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

will _never_ be able to ask all the right questions. _Never_. So to put that requirement on them is just our 'easy way out' of the problem. -- Michael > -- > Karen Goertzel, CISSP > Booz Allen Hamilton > 703-902-6981 > [EMAIL PROTECTED] > > > -Orig

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

/documentation/legal.html). Yes, I've read the before, and even discussed it with you! :) -- Michael > > --Jeff > > > > >> - Original Message - > >> From: "Michael Silk" <[EMAIL PROTECTED]> > >> To: "Kenneth

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

on. This would make it, then, compulsory for small businesses to have insurance to cover the cost of being sued by large corporations - and that amount of coverage might not be possible for small companies. > See you at OWASP England. Unfortunately not, a little bit too far for me at th

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

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 &g

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

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 prog

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

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 you be on a call and have it update itself?) Personally, I would prefer a phone that doesn't connect to the internet at all rather