Re: [SC-L] Need a help for an article

2013-06-04 Thread vanderaj vanderaj
Hi Punit,

Good on you for selecting information security as a topic of interest.
We need more grads in our field!

The state of the art for buffer overflows, heap overflows, and other
memory corruption bugs is so advanced that it may take you a little
while to get on top of it before being able to write about it simply
enough for the average Joe to understand it. They seem simple enough,
but there's so much nuance and almost an obsessive amount of detail to
get right to get a reliable exploit. Almost anyone can cause a program
to crash, but it's the freaks who can turn an unexploitable null
dereference bug into a workable exploit. To me, the freaks are more
interesting than the exploits.

I am not trying to dissuade you from writing about IT security, as
many programmers think that buffer overflows are solved due to ASLR
and DEP, or as soon as they use the /GS switch. This is not the case -
it just makes it much harder. So it's not an old topic, it's now an
extremely arcane topic.

How much time do you want to invest in writing your article? I would
suggest going down a different route - find the usual suspects on
SlideShare, Twitter or Google+ who REALLY knows their stuff and ask
them for an interview them to get the human angle on modern day memory
exploitation trickery. This way, you don't need to necessarily master
the issue, and you can report on the state of the art with a human
angle.

I would suggest searching for anyone who does reverse engineering for
fun or a living who has  200-500 followers as being a good starting
point. The big names in our industry are generally interesting folks
in their own right. In the old days, we'd call them eccentric, and to
me, this is the angle that I would take time to read if done right.

thanks,
Andrew

On Tue, Jun 4, 2013 at 1:22 AM, Punit Mehta punit9...@gmail.com wrote:
 Hi all ,

I am a second year computer science undergraduate
 student at a university. I want to publish an article based on computer
 security. I had thought of some like Buffer Overflow , Heap Overflow ,
 Format String attack etc. But they sound too old. My aim is to publish some
 fresh and interesting stuff based on computer security. I have searched a
 lot But may be because of my limited knowledge , I am not able to find out
 appropriate topics to work on . So , it would be grateful if someone could
 suggest me some nice , recent topics ( which can include secure coding in
 different languages or even beyond that ). I just want to get the topic and
 pointer to some resources from which I can learn it.

 Any kind of help is hearty welcomed..! :)

 Thanks in advance !

 Regards,
 Punit Mehta

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

___
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] SANS Institute - CWE/SANS TOP 25 Most Dangerous ProgrammingErrors

2009-01-12 Thread vanderaj vanderaj
Tom,

From the business' point of view, they really don't care if widget X
has weaknesses, they want to know how to make money by buying and
using widget X. They assume X is safe by default, even though it's
not. They've been doing fast and crappy for so long, and made heaps of
money from it, that it's a hard sell in many places to do the safer
thing until the horse has bolted.

The only examples where folks buy widget X over widget Y is those
folks in operational risk who have to make a financial allowance for a
probable risk difference between X and Y. For example, if one
satellite launch system blows up one time every four launches, and
another blows up one time every eight launches, you'd go with the
second or you'd have to budget for the likelihood of having to replace
your satellite a bit more with the first one.

In our industry, we have still yet to make a compelling, measurable
and thus believable case that there's a TCO benefit from buying more
expensive, but safer software. Most folks believe all software is
safe, despite the fact that it is not. Until that time, CWE and
similar *weakness* patterns are a derivative of the actual cost of
ownership, and not the actual benefits.

That's why I've gone gung ho into build it right the first time
mode. I doubt we'll get the accurate metrics required for proof that
safer software is cheaper (over time), so it's best that we simply get
safer software - period. That's why I will be working with the
frameworks and code repositories rather than the 0day crowd. In my
view, there is zero value in vulnerability disclosure, discussion, or
discovery. It's like shooting fish in a barrel.

thanks,
Andrew

 Will business start to talk CWE as they already talk CVE?

 Discussion/Debate/Thoughts

 Tom Brennan

___
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.
___