[SC-L] Fwd: IEEE W/NV Computer Society Presentation

2011-03-15 Thread Benjamin Tomhave
fyi - of potential interest to this crowd (even if it does sound a bit
sales-pitchy)...

 Original Message 
Subject: IEEE W/NV Computer Society Presentation
Date: Tue, 15 Mar 2011 07:00:00 -0400
From: IEEE E-Notice owner-ieee-e-not...@bmsmail3.ieee.org
Reply-To: sta...@ieee.org
To: fal...@secureconsulting.net

Quality  Security Mesh within the
Systems Development Life Cycle
by: Rhonda Farrell
Tuesday March 22, 2011

Synthesizing security throughout the SDLC takes the same concerted
effort as implementing quality programs across an organization.
Oftentimes, this requires that EVERYONE be empowered and responsible for
enabling and implementing these new processes in a rational, phased
approach.

This discussion highlights the benefits of ensuring security is built
in at every step of the SDLC versus bolted on at the end. Learn how
your organization can take the next step towards achieving higher levels
of both quality and security, by involving each and every person!

Rhonda Farrell Associate, Booz Allen Hamilton, is a Certified Software
Quality Engineer (CSQE), a Certified Information Systems Security
Professional (CISSP), and a Certified Secure Software Lifecycle
Professional (CSSLP). She recently earned her JD from Concord Law School
and is currently pursuing her Doctorate in Information Assurance at the
University of Fairfax.  Rhonda is a Senior Member of the American
Society for Quality (ASQ) and is a Member of the Executive Board
(Membership Chair; co-chair for the LSS-SIG), for Section 509.  She also
holds a board level position with the Information Systems Security
Association Northern VA (ISSA-NOVA) organization, as the VP of Education.

Additionally she participates as an officer, volunteer, or basic member
with the following organizations: Association for Computing Machinery
(ACM), Institute of Electrical and Electronics Engineers (IEEE),
Information Systems Audit and Control Association (ISACA), International
Information Systems Security Certification Consortium, Inc. (ISC2),
National Marine Corps League (MCL), Software Development Forum
(SDForum), Silicon Valley Software Quality Association (SSQA-SV), and
Woman Marines Association (WMA).

She brings a wide breadth of experience in the operations, engineering,
security, marketing, and training areas from having previously worked
within private enterprise, state government, non-profit, educational,
and military organizations.

6:30 PM – Networking and Pizza(*); 7:00 - 8:00 PM – Program
(*) There is no cost to attend at McLean and Silver Spring.
Locations: The presentation will originate at the McLean facility, with
video tele-conferencing (VTC) between:

MITRE, room 1N100
7515 Colshire Drive
McLean, VA 22102
host: Scott Ankrum
cell: 240-731-7581

FDA, Bld 66, room G512
10903 New Hampshire Ave
Silver Spring, MD 20993
host: James Simpson
cell: 301-996-4976

MITRE, room 2503
260 Industrial Way West
Eatontown, NJ 07724
host: Richard Eng
cell: 703-201-9112  

MITRE, room 1M306
202 Burlington Rd (Rt. 62)
Bedford, MA 01730
host: Tim Rice
cell: 978-758-2704

If you can host another location via VTC, please contact Scott Ankrum

Registration Website: http://www.asq509.org/ht/d/DoSurvey/i/26913

For more details and driving directions, see:
http://www.asq509.org/ht/a/GetDocumentAction/i/58243


You have received this mailing because you are a member of IEEE Northern
VA/Washington Computer Chapter
http://ewh.ieee.org/r2/wash_nova/computer/cms/.

To unsubscribe, please go to
http://ewh.ieee.org/enotice/options.php?SN=TomhaveLN=CHAPTER and be
certain to include your IEEE member number.

If you need assistance with your E-Notice subscription, please contact
k.n@ieee.org


IEEE, 445 Hoes Lane, Piscataway, NJ 08854 USA


-- 
Benjamin Tomhave, MS, CISSP
tomh...@secureconsulting.net
Blog: http://www.secureconsulting.net/
Twitter: http://twitter.com/falconsview
LI: http://www.linkedin.com/in/btomhave

[ Random Quote: ]
There are two kinds of people in the world, those who believe there are
two kinds of people in the world and those who don't.
Robert Benchley
___
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
___


[SC-L] BSides Austin 2011 CFP / CFS

2011-01-18 Thread Benjamin Tomhave
Greetings and solicitations!

We're pleased as punch to announce the 2nd annual Security BSides Austin
2011: Keep Security Weird! Planning is well underway for this year's
event, which will be held March 11-12 in Austin, TX, conveniently during
the same time SXSW Interactive (a major developer conference). One of
our primary objectives in hosting opposite SXSW is to provide FREE
appsec training and presentations to developers who are in town for the
event. Our long-term goal is to become an officially sanctioned SXSW event.

To make this event as outstanding as possible, we need your help!

Here's how:

 * Speak! The CFP is open. Please register and submit your talk, or just
leave a comment if you don't want to register on the site.

 * Attend! Register to attend at http://bsidesaustin2011.eventbrite.com/

 * Sponsor! BSides events are free to attendees, which means we rely
exclusively on sponsors. If you're willing to contribute, please drop us
a note and we'll follow-up. Sponsorship is a great way to make a
low-cost investment in the industry while getting your name out there
and associated with one of the hottest events around!

In addition to traditional talks and unconference sessions, we are also
in the process of setting-up an AppSec Guerrilla Camp track where free
hands-on workshops will be provided on appsec topics. These 1-2 hour
sessions will be technical in nature and specifically oriented to
developers.

More information is available from the official event website:
http://www.keepsecurityweird.org/

Please feel free to contact me directly (off-list) if you have questions
or are interested in helping out!

Thank you,

-ben

-- 
Benjamin Tomhave, MS, CISSP
tomh...@secureconsulting.net
Blog: http://www.secureconsulting.net/
Twitter: http://twitter.com/falconsview
LI: http://www.linkedin.com/in/btomhave

[ Random Quote: ]
Computers are like very dumb people, but they're very fast at being
dumb, says Jason Hong, a professor at Carnegie Mellon's Human-Computer
Interaction Institute (HCII).
Washington Post (10/7/07 p.M01) This Is Your Life: As Determined by
Confounding Identity-Protection Safeguards By Monica Hesse

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


[SC-L] RSnake's final post

2010-12-01 Thread Benjamin Tomhave
In case you don't follow his blog... Rob RSnake Hanson has concluded
his security blog, though he says he will continue in security for the
time being. Nonetheless, a reasonably notable event anytime a prominent
persona in this small community decides to all but walk away.
http://ha.ckers.org/blog/20101201/and-beyond

-- 
Benjamin Tomhave, MS, CISSP
tomh...@secureconsulting.net
Blog: http://www.secureconsulting.net/
Twitter: http://twitter.com/falconsview
LI: http://www.linkedin.com/in/btomhave

[ Random Quote: ]
Champions aren't made in gyms. Champions are made from something they
have deep inside them - a desire, a dream, a vision. They have to have
last-minute stamina, they have to be a little faster, they have to have
the skill and the will. But the will must be stronger than the skill.
Muhammad Ali

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


[SC-L] Java: the next platform-independent target

2010-10-20 Thread Benjamin Tomhave
All these platform-independent attacks are starting to get exhausting,
no? Now that Adobe has come up with sandboxing for Reader and actually
started responding to threats, it seems that the smart adversaries have
moved to a new platform: Java. Stories are below, mostly deriving from
Microsoft's latest Intelligence Report (this one has a botnet focus - a
topic on which they've invested a ton of resources).

If I understand this all correctly (never a safe bet), it seems these
are actual attacks on Java, not on coding with Java. Ergo, this isn't
something ESAPI can fix, but rather fundamental problems. What do you
think? Overblown? Legit? Solutions forthcoming?

The rise of Java exploits
http://www.net-security.org/secworld.php?id=10014

Have you checked the Java?
http://blogs.technet.com/b/mmpc/archive/2010/10/18/have-you-checked-the-java.aspx

Java: A Gift to Exploit Pack Makers
http://krebsonsecurity.com/2010/10/java-a-gift-to-exploit-pack-makers/

Announcing Microsoft Security Intelligence Report version 9
http://blogs.technet.com/b/mmpc/archive/2010/10/13/announcing-microsoft-security-intelligence-report-version-9.aspx

cheers,

-ben

-- 
Benjamin Tomhave, MS, CISSP
tomh...@secureconsulting.net
Blog: http://www.secureconsulting.net/
Twitter: http://twitter.com/falconsview
LI: http://www.linkedin.com/in/btomhave

[ Random Quote: ]
I ran into Isosceles. He had a great idea for a new triangle!
Woody Allen

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


[SC-L] free scans from Google...

2010-03-20 Thread Benjamin Tomhave
I guess we can all retire now, eh? I find it so exciting that the app is
written in pure C... and coming from Google, I'm sure it won't leak
info back to the mothership at all...

Meet skipfish, our automated web security scanner
http://googleonlinesecurity.blogspot.com/2010/03/meet-skipfish-our-automated-web.html

-- 
Benjamin Tomhave, MS, CISSP
tomh...@secureconsulting.net
Blog: http://www.secureconsulting.net/
Twitter: http://twitter.com/falconsview
LI: http://www.linkedin.com/in/btomhave

[ Random Quote: ]
Do you think that when they asked George Washington for ID that he just
whipped out a quarter?
Steven Wright

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


[SC-L] sponsors still needed for BSides Austin

2010-03-08 Thread Benjamin Tomhave
Hi folks,

We need your help. We're still looking for sponsors for this weekend's
Security BSides Austin, which is set to occur the same day as the
kickoff for SxSW Interactive (a major developer conference). We have
official sponsorship from Astaro and Panda, plus a couple unofficial
sponsors. We'd love to see your organization involved, too!

Unconference details here:
http://www.securitybsides.com/BSidesAustin

Here are some benefits for sponsoring:
* Being part of the media conversation: As people talk about us they
talk about you or at least see you.  Security B-Sides has been covered
in magazines, podcasts, videocasts, blogs, and even inscribed on
microchips.  Get caught up in the conversation and be part of what
people are talking about.
* Brand recognition and awareness: Depending on the level of
sponsorship, you may recognize your brand placement at some or all of
the following: t-shirts, signage/lanyards, lunch sessions, or attendee
badges. Based on your level of participation, create and custom branding
may be arranged including transportation, banners, and podcast interviews.
* Big Fish in a Small Pond: For some, sponsoring large events is not
within their price range leaving them with no option for communicating
their message. BSides is just the place for you! This small, community
atmosphere brings together active and engaged participants who want to
absorb information. Sponsoring a BSides event enables to be that big
fish in a small pond and better communicate your message to an active
audience.
* Stay in touch with the industry: BSides enables its supporters and
participants to identify and connect with industry leaders and voices.
These participants represent the social networking of security. They are
the people who you want to engage to solicit feedback and bring voice to
your conversation.
* Targeted and Direct Audience: You didn't enter the secrutity
industry selling your product to everyone the same way, so why approach
events that way?  Instead of marketing to the broader security
community connect directly with the security practioners who write
about, talk about, recommend, and implement security products and services.
* Be associated with the next big thing: Nobody knows what the “next
big thing” will be, but these events are community driven with
presentations voted upon by the industry. There is no magic to how it
works, but we believe that listening to the underground can help prepare
you and help identify what the next big thing might be.

Thank you,

-ben

-- 
Benjamin Tomhave, MS, CISSP
tomh...@secureconsulting.net
Blog: http://www.secureconsulting.net/
Twitter: http://twitter.com/falconsview
LI: http://www.linkedin.com/in/btomhave

[ Random Quote: ]
How young can you die of old age?
Steven Wright

___
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] web apps are homogenous?

2010-02-26 Thread Benjamin Tomhave
Jon,

I think you're getting out of the scope of the costing exercise. The
research and estimates around time to fix are based on the cost
associated with developing the patch, not with deploying it. One could
argue that the cost of fixing bugs - particularly major ones - is much
higher for web applications given that they are more likely to be
rapidly deployed and that the discovery of the bug is more likely to be
widely publicized (especially if it leads to a breach). Everybody has a
reasonable expectation that widely deployed commercial software is going
to have various bugs over its life (e.g. Windows, Adobe products), while
people seem to still be generally surprised when holes pop-up in web apps.

Now, that being said, it is still a valid question as to if there is a
cost differential between fix classic compiled code and modern web code.
Toward that end, I would recommend looking into Laurie Williams' work at
NCSU. She has inherited John Musa's Software Reliability Engineering
legacy, is active in the field, and has published a number of articles
and papers potentially relevant to this field. See:
http://collaboration.csc.ncsu.edu/laurie/

fwiw.

-ben

On 2/25/10 1:56 AM, Jon McClintock wrote:
 On Wed, Feb 24, 2010 at 10:46:56AM -0500, Paco Hope wrote:
 I don't think webness conveys any more homogeneity than, say
 windowsness or linuxness.
 
 What part of being a web application provides homogeneity in a way
 that makes patching cheaper?
 
 In a word, control. Let's compare two different organizations: a 
 commercial software development company, and a web commerce company. 
 They both develop software, but how the software is deployed and
 managed is widely different.
 
 Commercial software is created by one party, and consumed by
 multiple other parties. Those parties may run it in widely different
 operating environments, with different network, software and harware 
 configurations. They may be running old versions of the software, or 
 using it in novel ways.
 
 If the commercial software development company has to patch a 
 vulnerability, they need to first determine which releases of the 
 software need to be patched, develop and test a patch for each
 supported version, test it across the plethora different
 configurations their customers may be running, develop release notes
 and a security advisory, make the patch available, and support their
 customers while they are patching.
 
 For a web commerce company, however, the picture is entirely
 different. While their production fleet may comprise hundreds, or
 even thousands, of servers, they're likely all running the exact same
 software and configuration, using a configuration management system
 to deploy the website software and keep it in sync.
 
 If the web commerce company identifies a vulnerability in their
 website, they can debug the running stack, create a fix, test it
 against an exact replica of the production stack, and use automated
 tools to deploy the patch to their entire fleet in one operation.
 
 -Jon
 
 
 
 ___ 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. 
 ___

-- 
Benjamin Tomhave, MS, CISSP
tomh...@secureconsulting.net
Blog: http://www.secureconsulting.net/
Twitter: http://twitter.com/falconsview
LI: http://www.linkedin.com/in/btomhave

[ Random Quote: ]
Oh, so they have internet on computers now!
Homer Simpson
___
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] seeking hard numbers of bug fixes...

2010-02-23 Thread Benjamin Tomhave
Ah, excellent - very helpful!

It appears that Laurie Williams at NCSU has inherited John Musa's
Software Reliability Engineering legacy, and is still active in the
field, and has a number of relevant security articles/papers listed
under Publications.
http://collaboration.csc.ncsu.edu/laurie/

On 2/22/10 11:22 AM, Wall, Kevin wrote:
 Benjamin Tomhave wrote:
 ... we're looking for hard research or
 numbers that covers the cost to catch bugs in code pre-launch and
 post-launch. The notion being that the organization saves itself money
 if it does a reasonable amount of QA (and security testing)
 up front vs trying to chase things down after they've been identified
 (and possibly exploited).
 
 Ben,
 
 Not sure if this is what you are looking for or not, but back in the
 mid- to late-1980s or so, John Musa, a DMTS at Bell Labs, wrote up a
 couple of papers that showed this data, although this was in the more
 general context of software quality assurance and not specific to
 security testing.
 
 I'm pretty sure that Musa published something in either one of the ACM
 or IEEE CS journals and included some hard data, collected from a bunch
 of (then ATT) Bell Labs projects. IIRC, the main finding was something
 like the cost was ~100 times more to catch and correct a bug during
 the normal design / coding phase than it was to catch / correct it
 after post-deployment.
 
 Can't help you much more than that. I'm surprised I remembered that much! :)
 
 -kevin
 ---
 Kevin W. Wall   Qwest Information Technology, Inc.
 kevin.w...@qwest.comPhone: 614.215.4788
 It is practically impossible to teach good programming to students
  that have had a prior exposure to BASIC: as potential programmers
  they are mentally mutilated beyond hope of regeneration
 - Edsger Dijkstra, How do we tell truths that matter?
   http://www.cs.utexas.edu/~EWD/transcriptions/EWD04xx/EWD498.html
 
 
 
 This communication is the property of Qwest and may contain confidential or
 privileged information. Unauthorized use of this communication is strictly
 prohibited and may be unlawful.  If you have received this communication
 in error, please immediately notify the sender by reply e-mail and destroy
 all copies of the communication and any attachments.
 
 

-- 
Benjamin Tomhave, MS, CISSP
tomh...@secureconsulting.net
Blog: http://www.secureconsulting.net/
Twitter: http://twitter.com/falconsview
LI: http://www.linkedin.com/in/btomhave

[ Random Quote: ]
Happiness makes up in height for what it lacks in length.
Robert Frost
___
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.
___


[SC-L] seeking hard numbers of bug fixes...

2010-02-22 Thread Benjamin Tomhave
Howdy,

This request is a bit time critical as it's supporting a colleague's
upsell up the food chain tomorrow... we're looking for hard research or
numbers that covers the cost to catch bugs in code pre-launch and
post-launch. The notion being that the organization saves itself money
if it does a reasonable amount of QA (and security testing) up front vs
trying to chase things down after they've been identified (and possibly
exploited).

Any help?

Thank you,

-ben

-- 
Benjamin Tomhave, MS, CISSP
tomh...@secureconsulting.net
Blog: http://www.secureconsulting.net/
Twitter: http://twitter.com/falconsview
LI: http://www.linkedin.com/in/btomhave

[ Random Quote: ]
Imagination is everything. It is the preview of life's coming attractions.
Albert Einstein
___
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] A massive change at DARPA

2010-02-11 Thread Benjamin Tomhave
I think it's a welcome change. It doesn't say so in this article clip,
but he is Dr. Zatko, and has worked in instruction and academia, so it's
not too far a leap for them. He's also been working in the federal space
quite a bit since the L0pht sold out and shutdown. Dan Geer did
something similar a couple years ago when he joined In-Q-Tel.

On 2/11/10 8:42 AM, Jeremy Epstein wrote:
 OK, many of you don't care about DARPA, but here's something that
 happened there you *should* care about.  DARPA funds research, and has
 historically drawn its program managers from the ranks of academia and
 occasionally the military.  This is a massive change in outlook
 
 
 http://news.cnet.com/8301-27080_3-10450552-245.html
 
  Peiter Zatko--a respected hacker known as Mudge--has been tapped to
 be a program manager at DARPA, where he will be in charge of funding
 research designed to help give the U.S. government tools needed to
 protect against cyberattacks, CNET has learned.
 
 Zatko will become a program manager in mid-March within the Strategic
 Technologies Office at DARPA (Defense Advanced Research Projects
 Agency), which is the research and development office for the
 Department of Defense. His focus will be cybersecurity, he said in an
 interview with CNET on Tuesday.
 
 One of his main goals will be to fund researchers at hacker spaces,
 start-ups, and boutiques who are most likely to develop technologies
 that can leapfrog what comes out of large corporations. I want
 revolutionary changes. I don't want evolutionary ones, he said.
 
 He's also hoping that giving a big push to research and development
 will do more to advance the progress of cybersecurity than public
 policy decisions have been able to do over the past few 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.
 ___
 
 

-- 
Benjamin Tomhave, MS, CISSP
tomh...@secureconsulting.net
Blog: http://www.secureconsulting.net/
Twitter: http://twitter.com/falconsview
LI: http://www.linkedin.com/in/btomhave

[ Random Quote: ]
What if everything is an illusion and nothing exists? In that case, I
definitely overpaid for my carpet.
Woody Allen
___
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] BSIMM update (informIT)

2010-02-03 Thread Benjamin Tomhave
 based on past findings. Therefore,
 I also would challenge BSIMM to publicly make some specific predictions
 using their model and collected data so that their hypotheses can be
 tested independently by others.

 Finally, while I would like, as you did, to blame our Computer Security /
 software security's Cargo Cult mentality on its relative youth as
 a field, I believe there is something deeper going on here. For one,
 computer science / IT / whatever you want to call this much broader
 field has the same issue. And while computer science is young as
 measured against most other scientific disciplines, it is by no means an
 immature field. (As a discipline, it is much older than I, and trust me,
 I am no spring chicken. :)

 After observing this field for 30+ years (ouch!), I have concluded that we
 have not matured into a science because as a discipline we *do NOT
 really want to!*  We can't even decide if we want this study of computers
 / information processing / etc. to be a science, an engineering
 discipline, or a craft. (And some even would like it to be an art.)
 Most of us--myself included--are too lazy to do the disciplined work
 that true science requires, and that includes having enough guts to
 challenge the academic culture and *demand* funding to do well-designed
 scientific experiment in our discipline at our leading universities. IMO,
 if we fail to do this, CS is doomed to always remain a science wannabe.

 Some would say that because our broader field of study--whether you
 call it Computer Science, Computer Engineering, Information Science,
 whatever--is part science, part engineering, part craft, and part
 something unique that humanity has never before encountered, attempts
 to treat it as a science will not succeed. However, surely this does
 not mean that we should not attempt to add some scientific rigor to
 it as a discipline. To that end efforts such as BSIMM should be welcomed
 by all.  But is also important for those who prefer _descriptive_ approaches
 like BSIMM, to acknowledge the importance of _prescriptive_ approaches
 such as ESAPI, WAFs, anti-malware software, etc. We truly need *both*
 approaches to be successful.

 Regards,
 -kevin
 ---
 Kevin W. Wall   Qwest Information Technology, Inc.
 kevin.w...@qwest.comPhone: 614.215.4788
 It is practically impossible to teach good programming to students
  that have had a prior exposure to BASIC: as potential programmers
  they are mentally mutilated beyond hope of regeneration
- Edsger Dijkstra, How do we tell truths that matter?
  http://www.cs.utexas.edu/~EWD/transcriptions/EWD04xx/EWD498.html

 This communication is the property of Qwest and may contain confidential or
 privileged information. Unauthorized use of this communication is strictly
 prohibited and may be unlawful.  If you have received this communication
 in error, please immediately notify the sender by reply e-mail and destroy
 all copies of the communication and any attachments.

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

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

-- 
Benjamin Tomhave, MS, CISSP
tomh...@secureconsulting.net
Blog: http://www.secureconsulting.net/
Twitter: http://twitter.com/falconsview
LI: http://www.linkedin.com/in/btomhave

[ Random Quote: ]
Some of us will do our jobs well and some will not, but we will be
judged by only one thing-the result.
Vince Lombardi
___
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] BSIMM update (informIT)

2010-02-03 Thread Benjamin Tomhave
I challenge the validity of any risk assessment/rating approach in use
today in infosec circles, whether it be OWASP or FAIR or IAM/ISAM or
whatever. They are all fundamentally flawed in that they are based on
qualitative values the introduce subjectivity, and they lack the
historical data seen in the actuarial science to make the probability
estimates even remotely reasonable. FAIR tries to compensate for this by
using Bayesian statistics, but the qualitative-quantitative conversion
is still highly problematic.

On prescriptive... the problem is this: businesses will not spend money
unless they're required to do so. Security will never succeed without at
least an initial increased spend. It is exceedingly difficult to make a
well-understood business case for proper security measures and spend. I
think this is something you guys in insurance (you, Chris Hayes, etc.)
perhaps take for granted. The other businesses - especially SMBs - don't
even understand what we're talking about, and they certainly don't have
any interest in dropping a penny on security without seeing a direct
benefit.

Do I trust regulators to do things right? Of course not, but that's only
one possible fork. The other possible fork is relying on the courts to
finally catch-up such that case law can develop around defining
reasonable standard of care and then evolving it over time. In either
case, you need to set a definitive mark that says you must do THIS MUCH
or you will be negligent and held accountable. I hate standards like
PCI as much as the next guy because I hate being told how I should be
doing security, but in the short-to-mid-term it's the right approach
because it tells people the expectation for performance. If you never
set expectations for performance, then you shouldn't be disappointed
when people don't achieve them. The bottom line here is that we need to
get far more proactive in the regulatory space so that we can influence
sensible regulations that mandate change rather than relying on
businesses to do the right thing without understand the underlying
business value.

Conceptually, I agree with the idealist approach, but in reality I don't
find that it works well at all. I've worked with a half-dozen or more
companies of varying size in the last couple years and NONE of them
understood risk, risk management, current security theory, or how the
implicit AND explicit value of security changes. It's just not intuitive
to most people, not the least of which because bad behaviors are
generally divorced from tangible consequences. Anyway... :)

I can go on forever on this topic... :)

-ben

On 2/3/10 10:06 AM, McGovern, James F. (eBusiness) wrote:
 While Wall Street's definition of risk collapsed, the insurance model of
 risk stood the test of time :-)
 
 Should we explore your question of how are risk levels defined in
 business terms more deeply or can we simply say that if you don't have
 your own industry-specific regulatory way of quantifying, a good
 starting point may be to leverage the OWASP Risk Rating system?
 
 I also would like to challenge and say NO to prescriptive. Security
 people are not Vice Presidents of the NO department. Instead we need to
 figure out how to align with other value systems (Think Agile
 Manifesto). We can be secure without being prescriptive. One example is
 to do business exercises such as Protection Poker.
 
 Finally, we shouldn't say yes to regulatory mandates as most of them are
 misses on the real risk at hand. The challenge here is that they always
 mandate process but never competency. If a regulation said that I should
 have someone with a fancy title overseeing a program, the business world
 would immediately fill the slot with some non-technical resource who is
 really good at PowerPoint but nothing else. In other words a figurehead.
 Likewise, while regulations cause people to do things that they should
 be doing independently, it has a negative side effect on our economy by
 causing folks to spend money in non-strategic ways.
 
 -Original Message-
 From: sc-l-boun...@securecoding.org
 [mailto:sc-l-boun...@securecoding.org] On Behalf Of Benjamin Tomhave
 Sent: Tuesday, February 02, 2010 10:19 PM
 To: Arian J. Evans
 Cc: Secure Code Mailing List
 Subject: Re: [SC-L] BSIMM update (informIT)
 
 soapboxWhile I can't disagree with this based on modern reality, I'm
 increasingly hesitant to allow the conversation to bring in risk, since
 it's almost complete garbage these days. Nobody really understands it,
 nobody really does it very well (especially if we redact out financial
 services and insurance - and even then, look what happened to Wall
 Street risk models!), and more importantly, it's implemented so shoddily
 that there's no real, reasonable way to actually demonstrate risk
 remediation/reduction because talking about it means bringing in a whole
 other range of discussions (what is most important to the business?
 and how are risk levels defined in business terms

Re: [SC-L] NIST SP 800-37

2010-02-03 Thread Benjamin Tomhave
800-37 has been in release for a while, providing the basis for the CA
process. My understanding is that CA is evolving (and going the way of
the dinosaur) very soon as NIST works with CNSS/JTF on the next big
thing. I'm blanking on the rest of the details (not my space), but
pinging Mike Smith (@rybolov) or Dan Philpott (@danphilpott) on Twitter
would likely be a good starting point.

On 2/3/10 1:12 PM, McGovern, James F. (eBusiness) wrote:
 NIST has created a draft document entitled: Guide for applying risk 
 management framework to federal information systems: a security 
 lifecycle approach. Curious to know if anyone has identified gaps, 
 differences in opinion, etc between NIST and how either SAMM or
 BSIMM would define the same?
 
  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 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. 
 ___

-- 
Benjamin Tomhave, MS, CISSP
tomh...@secureconsulting.net
Blog: http://www.secureconsulting.net/
Twitter: http://twitter.com/falconsview
LI: http://www.linkedin.com/in/btomhave

[ Random Quote: ]
Opportunity is missed by most people because it is dressed in overalls
and looks like work.
Thomas A. Edison
___
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.
___


[SC-L] How a stray mouse click choked the NYSE cost a bank $150K

2010-01-28 Thread Benjamin Tomhave
NYSE has come out with findings on a Credit Suisse initiated DOS
issue... something so small, yet so fundamentally flawed...

http://arstechnica.com/business/news/2010/01/how-a-stray-mouse-click-choked-the-nyse-cost-a-bank-150k.ars

-- 
Benjamin Tomhave, MS, CISSP
tomh...@secureconsulting.net
Blog: http://www.secureconsulting.net/
Twitter: http://twitter.com/falconsview
LI: http://www.linkedin.com/in/btomhave

[ Random Quote: ]
Science is facts; just as houses are made of stones, so is science made
of facts; but a pile of stones is not a house and a collection of facts
is not necessarily science.
Henri Poincare
___
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] Blog skiiers versus snowboarders CISSPs vs programmers

2010-01-13 Thread Benjamin Tomhave
I'm not even sure why we're talking about CISSPs in this regard. Having
a CISSP proves nothing; it's merely a blind HR/recruiter checklist item.
I've personally met dozens of CISSPs who can't answer the most basic of
security questions.

The short-term comes down to what Gary talked about recently, which is
getting a software security group (or team) established and functioning
well. Over time, outreach and education run by the SSG then begins to
permeate the organization until, hopefully, some day, the SSG can shrink
or dissolve and let security stand on its own. We obviously have a long
way to go as an industry before we reach that point.

fwiw.

-ben

Arian J. Evans wrote:
 The software security problem is a huge problem. There are not enough
 CISSPs to even think about solving this problem.
 
 CISSPs probably should have a tactical role helping categorize,
 classify, and facilitate getting things done. Scanner jockeys and
 network security folk will lead the operational charge to WAF and
 block and such. (good or bad, you're gonna need this stuff, the
 problem is just too darn big)
 
 I don't think many good devs who enjoy building are going to want to
 change careers to do source code audits. That gets mind numbing
 awfully fast.
 
 Developers definitely have a role to play in solving a lot of the
 basic syntax-attack stuffs, by proper selection and application of
 modern frameworks, technologies, and gap-APIs (like ESAPI). Most
 CISSPs lack the skill to provide much value here.
 
 Design issues will always exist, unless users some day wake up and
 decide they prefer security over usability. But I don't see that
 happening any time soon. Heck, my password on all my work machines is
 password.
 
 $0.02 USD.
 
 ---
 Arian Evans
 capitalist marksman. eats animals.
 
 
 
 On Tue, Jan 12, 2010 at 8:44 AM, Matt Parsons mparsons1...@gmail.com wrote:
 I wrote a blog in the state of software security using the analogy of skiers
 versus snowboarder in the early 90's.

 Please let me know your thoughts and comments by replying to this list or my
 blog.

 http://parsonsisconsulting.blogspot.com/



 Thanks,
 Matt



 Matt Parsons, MSM, CISSP
 315-559-3588 Blackberry
 817-294-3789 Home office
 mailto:mparsons1...@gmail.com
 http://www.parsonsisconsulting.com
 http://www.o2-ounceopen.com/o2-power-users/
 http://www.linkedin.com/in/parsonsconsulting
 http://parsonsisconsulting.blogspot.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
 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.
 ___

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

-- 
Benjamin Tomhave, MS, CISSP
tomh...@secureconsulting.net
Blog: http://www.secureconsulting.net/
Twitter: http://twitter.com/falconsview
LI: http://www.linkedin.com/in/btomhave

[ Random Quote: ]
I have no special talent. I am only passionately curious.
Albert Einstein
___
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] InformIT: You need an SSG

2010-01-13 Thread Benjamin Tomhave
Thanks for that excellent and detailed response, Steve. A few follow-up
questions:
1) What sort of charter and executive support was/is necessary to
establish a group like SSG, and to continue building on it? In
particular, I wonder about how the mandate was established, and then
supported over the year(s)?

2) How long has it taken to go from no SSG to a well-functioning SSG?
What sort of ramp-up time was needed?

3) Is there a way to capture the SSG and IR approach into some sort of
copy-n-paste model or framework that could be used to expedite
replication within other orgs? Is it even realistic to think that this
approach can be easily replicated? (somewhat ties back into
mandate/support, I suppose)

Thank you,

-ben

-- 
Benjamin Tomhave, MS, CISSP
tomh...@secureconsulting.net
Blog: http://www.secureconsulting.net/
Twitter: http://twitter.com/falconsview
LI: http://www.linkedin.com/in/btomhave

[ Random Quote: ]
Any sufficiently advanced technology is indistinguishable from magic.
Arthur C. Clarke

Steve Lipner wrote:
 Thanks for looping me in Gary - this is an interesting topic and one
 that I do have an opinion about (no surprise).  (My apologies for the
 long delay responding - holidays and vacation rather than lack of
 interest).
 
 Microsoft created a central IR group before I joined the company, and
 we feel very strongly that the IR model we have is the right one.  As
 things have evolved today, we centralize response policy, customer
 communications, security researcher (vulnerability finder)
 communications, press outreach, emergency response, vulnerability and
 fix security analysis, and response to complex (multi-product)
 vulnerabilities.Individual product teams are responsible for
 building secure code, and if a vulnerability is found they're
 responsible for fixing it.  But we have central policies on update
 packaging and release so that we protect all customers in the same
 way and administrators don't have to learn a separate patching
 process for each product.
 
 For IR, the central group lets us speak with one voice to communities
 who would be confused or bothered by having to deal with a batch of
 different Microsofts.  It also allows us to build a team that can
 specialize in deep technical security analysis - how bad is the
 impact this bug, is it an instance of a broader pattern that we
 should be searching for, does the proposed fix in fact fix the
 underlying problem?  Answering those questions is specialized work,
 and it's unreasonable to expect that any but the biggest product
 groups could build or retain the necessary capability.  I could share
 horror stories from 2000 and 2001 when really competent developers
 told me that a vulnerability wasn't exploitable to run code and then
 we found that it was.  The competence to do that sort of analysis is
 a lot scarcer than the competence to write secure code - but
 vulnerabilities still arise, and the IR team needs the scarce kind of
 competence to plan the right response.
 
 For secure development, as I said above, we expect product teams to
 design and build secure software.  But for a company like Microsoft
 with a central commitment to security, a central SSG allows us to
 develop and enforce common policies for what secure means.  That's
 part of achieving the accountability (consequences) Ben refers to
 below.  The SSG is also the place where we update policies and
 requirements, and develop new tools and techniques.  The SDL tools
 (and guidance) that we've released at www.microsoft.com/sdl over the
 last year or so have all been developed in our SSG - most for our own
 in-house use.  The SSG serves as a consulting resource on secure
 design - an area where the right solution will vary from product to
 product, and where it's beneficial for product teams to be able to
 appeal to folks who are focused on security and see a lot of problems
 and solutions.  The final key role of the SSG is to provide the link
 back to vulnerability research (again something that only the biggest
 product teams could afford).  Our SSG (Microsoft Security Engineering
 Center or MSEC) is part of the same organization as our IR team
 (Microsoft Security Response Center or MSRC) and we work closely as
 we're analyzing new security vulnerabilities and working to build on
 them, find patterns, and identify and remove new classes of
 vulnerabilities.  The idea (I used to think it came from Earl Boebert
 but I believe he was quoting Rick Proto) is that theories of security
 come from theories of insecurity.
 
 We fully understand the need to keep MSEC from getting too large.
 Our budget and planning process are part of our answer to doing that
 - we're essentially a support function, and nobody wants that to get
 too large.  We also avoid taking on tasks that should fall to product
 groups - I guess I could imagine a negative spiral where we did more
 and more of the work that product groups should do, and then had to
 get larger and larger

Re: [SC-L] [Esapi-user] [Esapi-dev] Recommending ESAPI?

2010-01-13 Thread Benjamin Tomhave
 building
 any Java app without ESAPI. :) (please note the I
 statement - I've been deep in the code for years, I'm not
 saying its easy - it requires significant investment of
 time to use all of ESAPI as it stands today).

 Another 18 hour day - I need sleep. :)

 Regards,
 - Jim

 ___
 Esapi-dev mailing list
 esapi-...@lists.owasp.org mailto:esapi-...@lists.owasp.org
 https://lists.owasp.org/mailman/listinfo/esapi-dev


 
 
 -- 
 Jim Manico
 OWASP Podcast Host/Producer
 http://www.manico.net
 
 
 
 ___
 Esapi-user mailing list
 esapi-u...@lists.owasp.org mailto:esapi-u...@lists.owasp.org
 https://lists.owasp.org/mailman/listinfo/esapi-user
 
 
 
 
 
 ___
 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.
 ___

-- 
Benjamin Tomhave, MS, CISSP
tomh...@secureconsulting.net
Blog: http://www.secureconsulting.net/
Twitter: http://twitter.com/falconsview
LI: http://www.linkedin.com/in/btomhave

[ Random Quote: ]
When will I learn? The answer to life's problems aren't at the bottom
of a bottle, they're on TV!
Homer Simpson
___
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.
___


[SC-L] new post: The Three Domains of Application Security

2010-01-11 Thread Benjamin Tomhave
Of interest, I hope...
http://www.secureconsulting.net/2010/01/the_three_domains_of_applicati.html

-- 
Benjamin Tomhave, MS, CISSP
tomh...@secureconsulting.net
Blog: http://www.secureconsulting.net/
Twitter: http://twitter.com/falconsview
LI: http://www.linkedin.com/in/btomhave

[ Random Quote: ]
The unquestionable republicanism of the American mind will break
through the mist under which it has been clouded, and will oblige its
agents to reform the principles and practices of their administration.
Thomas Jefferson to Elbridge Gerry, 1799. ME 10:83
___
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] Checklist Manifesto applicability to software security

2010-01-07 Thread Benjamin Tomhave
I think there's lots of applicability. People - especially techies - cut
corners. The pressure is usually to get things done in a certain amount
of time, and then add on that people like to generally expend as little
energy as possible, and viola! you see the problem.

Of course, the flip side is that checklists in an area like IT can be
detrimental, too. PCI is a great example, where it never made a claim of
being comprehensive, yet is treated as such (and codified in State laws
for crying out loud), and then orgs still get hacked, leaving them to
wonder why the checklist didn't protect them.

Perhaps the key, then, is knowing that you need experience+procedures.
Procedures allow you to not screw up the mundane and routine, while
experience allows you to dynamically respond to issues that don't fit
the precise steps of the procedure. Part and parcel to this, then, is
needing to empower experienced professionals to be flexible and dynamic
in the vast of challenges rather than requiring them to rigidly adhere
to procedure in all instances.

Within appsec, QA and related security testing is probably a great
example. If all QA could be strictly proceduralized, then you could just
automate it all. However, testing doesn't always go as expected,
requiring a functioning brain to (hopefully) respond and adapt
accordingly. You probably need procedures for properly catching those
exceptions, but nonetheless, those procedures automatically create a
capacity for dynamic response.

Sorry, a bit rambly...

-ben

Jeremy Epstein wrote:
 Greetings,
 
 I was listening yesterday to an interview [1] on NPR with Dr. Atul
 Gawande, author of Checklist Manifesto [2].  He describes the
 problem that medical procedures (e.g., surgery) tend to have lots of
 mistakes, mostly caused because of leaving out important steps.  He
 claims that 2/3 of medical - or maybe surgical - errors can be avoided
 by use of checklists.  Checklists aren't very popular among doctors,
 because they don't like to see themselves as factory workers following
 a procedure, because the human body is extremely complex, and because
 every patient is unique.
 
 So as I was listening, I was thinking that many of the same things
 could be said about software developers and problems with software
 security - every piece of software is unique, any non-trivial piece of
 software is amazingly complex, developers tend to consider themselves
 as artists creating unique works, etc.
 
 Has anyone looked into the parallelisms before?  If so, I'd be
 interested in chatting (probably offlist) about your thoughts.
 
 --Jeremy
 
 [1] Listen to the interview at http://wamu.org/programs/dr/10/01/06.php#29280
 [2] The Checklist Manifesto: How to Get Things Right, Atul Gawande,
 Metropolitan Books.
 ___
 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.
 ___
 
 

-- 
Benjamin Tomhave, MS, CISSP
tomh...@secureconsulting.net
Blog: http://www.secureconsulting.net/
Twitter: http://twitter.com/falconsview
LI: http://www.linkedin.com/in/btomhave

[ Random Quote: ]
Pareto Principle (a.k.a. “The 80-20 Rule”): For many phenomena, 80% of
consequences stem from 20% of the causes.
http://globalnerdy.com/2007/07/18/laws-of-software-development/
___
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.
___


[SC-L] seeking sponsors for SXSW Security BSides

2010-01-04 Thread Benjamin Tomhave
Hi folks!

For those not familiar, a handful of security people kicked off an
unconference styled event during Black Hat this past July in Las Vegas
termed Security BSides. The objective was to create a less formal
setting where top-notch security speakers/experts could have direct
conversations with people about topics of interest. The event was a huge
success. Please see http://www.securitybsides.com/ for more details.

Building on this success, a few more BSides events have started to
emerge. One such place where we hope to try this out as at SXSW
Interactive this coming March. Right now we are looking at hosting the
event on Saturday, March 13th. In keeping with the BSides tradition, the
idea is to find a venue that has adequate space for 100-200 people, as
well as lounge space to allow folks to hang out, chill out, socialize,
etc. In targeting SXSW, we're hoping to pull in attendees from the
conference (especially non-security developers, managers, etc.).

In order to make this happen, we need some help! We're looking for
sponsors (named or unnamed - up to you) to help underwrite the event.
BSides events do not charge attendees a fee in order to keep the format
and discussions open. Contributions of any size would be welcomed.
Support for past and future events includes monetary contributions,
materials, personnel, and transportation.

If you think you or your organization can help, please send email
directly to me (tomh...@secureconsulting.net) and we can get you more
information, discuss further, etc.

Thank you!

-ben

-- 
Benjamin Tomhave, MS, CISSP
tomh...@secureconsulting.net
Blog: http://www.secureconsulting.net/
Twitter: http://twitter.com/falconsview
LI: http://www.linkedin.com/in/btomhave

[ Random Quote: ]
It's not whether you get knocked down, it's whether you get up.
Vince Lombardi
___
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] InformIT: You need an SSG

2009-12-22 Thread Benjamin Tomhave
I think the short-term assertion is sound (setup a group to make a push
in training, awareness, and integration with SOP), but I'm not convinced
the long-term assertion (that is, maintaining the group past the initial
push) is in fact meritorious. I think there's a danger in setting up
dedicated security groups of almost any sort as it provides a crutch to
organizations that then leads to a failure to integrate security
practices into general SOP.

What is advocated seems to be consistent with how we've approached
security as an industry for the past couple decades (or longer), and I
don't see this as having the long-term benefit that was desired or
intended. It seems that when you don't make people directly responsible
and liable for doing the right things, they then fail at the ask and let
others do it instead. It's the old lazy sysadmin axiom that we script
repeatable tasks because it's easier in the long run.

The question, then, comes down to one of psychology and people
management. How do we make people responsible for their actions such
that they begin to adopt better practices? The basic response should be
to enact consequences, and I think that now is probably an optimal time
for businesses to get very hard-nosed about these sorts of things (high
unemployment means lots of people looking for work means employers have
the advantage). This perhaps sounds very ugly and nasty, and obviously
it will be if taken to an extreme, but we have a serious problem
culturally in that non-security people still don't seem to think, on
average, that security is in their job description. Solve that problem,
and all this other stuff becomes a footnote.

fwiw.

-ben

Gary McGraw wrote:
 hi sc-l,
 
 This list is made up of a bunch of practitioners (more than a
 thousand from what Ken tells me), and we collectively have many
 different ways of promoting software security in our companies and
 our clients.  The BSIMM study http://bsi-mm.com focuses attention
 on software security in large organizations and just at the moment
 covers the work of 1554 full time employees working every day in 26
 software security initiatives.  One phenomenon we observed in the
 BSIMM was that every large initiative has a Software Security Group
 (SSG) to carry out and lead software security activities.
 
 I wrote about our observations around SSGs in this month's informIT
 article:
 
 http://www.informit.com/articles/article.aspx?p=1434903
 
 Simply put, an SSG is a critical part of a software security
 initiative in all companies with more than 100 developers.  (We're
 still not sure about SSGs in smaller organizations, but the BSIMM
 Begin data (now hovering at 75 firms) may be revealing.)
 
 Cigital's SSG was formed in 1997 (with John Viega, Brad Arkin, and me
 as founding members).  Since its inception, we've helped plan, staff,
 and carry out ten large software security initiatives in customer
 firms.  One of the most important first tasks is establishing an SSG.
 
 
 Merry New Year everybody.
 
 gem
 
 company www.cigital.com podcast www.cigital.com/silverbullet blog
 www.cigital.com/justiceleague book www.swsec.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 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. 
 ___
 
 

-- 
Benjamin Tomhave, MS, CISSP
fal...@secureconsulting.net
Blog: http://www.secureconsulting.net/
Twitter: http://twitter.com/falconsview
Photos: http://photos.secureconsulting.net/
Web: http://falcon.secureconsulting.net/
LI: http://www.linkedin.com/in/btomhave

[ Random Quote: ]
The only source of knowledge is experience.
Albert Einstein
___
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] new job!

2009-10-18 Thread Benjamin Tomhave
Ditto on the new job for me, too! (thanks for reminder Dave)

I've taken a position with Foreground Security and will also be moving
back to NoVA. I start Monday and the movers come next Saturday. :)

Looks like Dave and I need to put our heads together and host a
NoVA-based thank you happy hour. :)

-ben

SC-L Reader Dave Aronson wrote:
 Since the Power that Be let me post my plea for job help, I figured
 I'd let y'all know the outcome.
 
 Long story short, I have accepted a position at Comcast, in the
 National Engineering and Technical Operations group, in Herndon VA
 (possibly moving to Reston VA soonish), starting in probably a week or
 two.  I will no longer be in a position related to security, but will
 still participate here, and in the broader secure coding community, as
 time allows -- and keep trying to spread the gospel.  ;-)
 
 Thanks for all your help,
 Dave
 

-- 
Benjamin Tomhave, MS, CISSP
fal...@secureconsulting.net
Blog: http://www.secureconsulting.net/
Twitter: http://twitter.com/falconsview
Photos: http://photos.secureconsulting.net/
Web: http://falcon.secureconsulting.net/
LI: http://www.linkedin.com/in/btomhave

[ Random Quote: ]
Practice does not make perfect. Only perfect practice makes perfect.
Vince Lombardi
___
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] Another WAF in town

2009-09-24 Thread Benjamin Tomhave
Define firewall in this context, I guess, right? Something that
controls network and application access, separate from the application
itself? I don't recall it being defined in PCI DSS itself, so I'm sure
it'll be fine so long as one can properly explain it to the QSA. :)

-ben

McGovern, James F (HTSC, IT) wrote:
 Interesting approach. Curious to know if this will satisfy a PCI
 auditor as a compensating control (section 6)
 
 -Original Message- From: sc-l-boun...@securecoding.org 
 [mailto:sc-l-boun...@securecoding.org] On Behalf Of Kenneth Van Wyk 
 Sent: Thursday, September 24, 2009 12:03 PM To: Secure Coding 
 Subject: [SC-L] Another WAF in town
 
 FYI, some activity in the open source WAF space:
 
 http://www.darkreading.com/security/app-security/showArticle.jhtml?artic
  leID=220100630
 
 Cheers,
 
 Ken
 
 - Kenneth R. van Wyk SC-L Moderator
 
  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 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. 
 ___
 
 

-- 
Benjamin Tomhave, MS, CISSP
fal...@secureconsulting.net
Blog: http://www.secureconsulting.net/
Twitter: http://twitter.com/falconsview
Photos: http://photos.secureconsulting.net/
Web: http://falcon.secureconsulting.net/
LI: http://www.linkedin.com/in/btomhave

[ Random Quote: ]
Perhaps in time the so-called Dark Ages will be thought of as including
our own.
Georg Christoph Lichtenberg
___
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.
___


[SC-L] OT: suddenly out of work

2009-09-23 Thread Benjamin Tomhave
Hi folks!

Sorry for the off-topic traffic, but I find myself suddenly without a
job today, without warning or severance. I'm currently based in Phoenix,
AZ, but am open to travel or relocation. I've been published, including
as the cover story for this month's ISSA Journal, have speaking
experience, and have been doing this work for nigh on 15 years. Full
resume is available here:
http://falcon.secureconsulting.net/resume/Ben_Tomhave.pdf

Thank you, and again apologies for interloping here,

-ben

-- 
Benjamin Tomhave, MS, CISSP
fal...@secureconsulting.net
Blog: http://www.secureconsulting.net/
Twitter: http://twitter.com/falconsview
Photos: http://photos.secureconsulting.net/
Web: http://falcon.secureconsulting.net/
LI: http://www.linkedin.com/in/btomhave

[ Random Quote: ]
The greatest challenge to any thinker is stating the problem in a way
that will allow a solution.
Bertrand Russell

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

2009-08-27 Thread Benjamin Tomhave
To be sure, inherently secure code is a misnomer. However, that being
said, my original contention was that certain common vulnerabilities
should be automatically managed these days rather than relying on
explicit code to catch them. Should any sort of overflow really be
allowed? I have to believe there are ways to safely trap those - perhaps
they result in an abend, but at least not in a manner that achieves the
goals of a compromise attempt. Similarly, it seems that there should be
ways to force the deserialization and parsing of data that could be
safer than allowing raw, unvalidated input to be acted upon.

I wonder, too, if part of the error in the curriculum thread is focusing
too low-level - that is, instead of focusing just on coding skills,
maybe there should also be a larger discussion of publishing frameworks,
development environments, etc., that introduce a lot of these security
capabilities as inherited properties/functions? Done properly, it would
lead to inherently better properties. fwiw.

-ben

Peter G. Neumann wrote:
 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.
 ___
 
 

-- 
Benjamin Tomhave, MS, CISSP
fal...@secureconsulting.net
Blog: http://www.secureconsulting.net/
Twitter: http://twitter.com/falconsview
Photos: http://photos.secureconsulting.net/
Web: http://falcon.secureconsulting.net/
LI: http://www.linkedin.com/in/btomhave

[ Random Quote: ]
We can't solve problems by using the same kind of thinking we used when
we created them.
Albert Einstein
___
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] Where Does Secure Coding Belong In the Curriculum?

2009-08-26 Thread Benjamin Tomhave
Matt Bishop wrote:
 
 Instead, what you can do is frame the issues as good programming. When
 teaching for loops, teach the idea of a limit (upper and lower
 bounds). Then when you get to arrays, it's natural to discuss bounds
 checking in the context of iteration (I don't phrase it that way, of
 course). When you grade, you check for it. Presto! Now you have taught
 what is commonly considered a security requirement without ever
 mentioning the word security.
 
I would agree with this, as I think it again syncs with what James
McGovern talked about earlier, too. A graduated approach to secure
coding (for whatever definition we might insert) is the only logical
progression. However, as you conceded, we have to be very careful just
how much we introduce and when. I remember the disconnect in the mid-90s
when the CompSci curriculum switched to OO. Some of us got caught in the
blender where our first CS class was non-OO and our 2nd class was
suddenly all OO and we didn't know what the heck was going on. It seems
we're perhaps still in this transitional state to a large part.

 By the way, you can do this very effectively in a beginning programming
 class. When I taught Python, as soon as the students got to basic
 structures like control loops (for which they had to do simple reading),
 I showed them how to catch exceptions so that they could handle input
 errors. When they did functions, we went into exceptions in more detail.
 They were told that if they didn't handle exceptions in their
 assignments, they would lose points -- and the graders gave inputs that
 would force exceptions to check that they did.
 
Let's just hope that the code isn't compiled with -O3 or similar,
creating an unintended bug. :)
http://isc.sans.org/diary.html?storyid=6820

 Most people got it quickly.
 
Getting it and applying it IRL are of course two completely different
things. I still find it somewhat absurd that we even need to have this
discussion still after how many decades of curriculum development? :)

-ben

-- 
Benjamin Tomhave, MS, CISSP
fal...@secureconsulting.net
Blog: http://www.secureconsulting.net/
Twitter: http://twitter.com/falconsview
Photos: http://photos.secureconsulting.net/
Web: http://falcon.secureconsulting.net/
LI: http://www.linkedin.com/in/btomhave

[ Random Quote: ]
Reading is to the mind what exercise is to the body.
Sir Richard Steele
___
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] Where Does Secure Coding Belong In the Curriculum?

2009-08-26 Thread Benjamin Tomhave
Goertzel, Karen [USA] wrote:
 We teach toddlers from the time they can walk that they shouldn't
 play in traffic. A year or two later, we teach them to look both ways
 before crossing the street. Even later - usually when they're
 approaching their teens, and can deal with grim reality, we give
 examples that illustrate exactly WHY they needed to know those
 things.
 
Actually, I'm not teaching my 1 yo toddler much of anything about
traffic right now. I'm more playing guardian when she runs around the
house and making sure she doesn't get into situations for which she
would be completely and totally unprepared (and in serious danger). She
lacks the language skills to even marginally understand basic concepts
like street let alone don't play in the street. I think this rather
proves my point that secure coding is not itself a fundamental concept,
but rather an intermediate-to-advanced concept. Matt Bishop's comments
are great, but they've also been applied in a context of higher ed., and
recognize the limits of student understanding at different phases of
development.

-ben

 But that doesn't mean we wait until the kids are 11 or 12 to tell
 them shouldn't play in traffic.
 
 There has to be some way to start introducing the idea even to the
 rawest of raw beginning programming students that good is much more
 desirable than expedient, and then to introduce the various
 properties that collectively constitute good - including security.
 
 Karen Mercedes Goertzel, CISSP Associate 703.698.7454 
 goertzel_ka...@bah.com  From:
 Andy Steingruebl [stein...@gmail.com] Sent: Tuesday, August 25, 2009
 1:14 PM To: Goertzel, Karen [USA] Cc: Benjamin Tomhave;
 sc-l@securecoding.org Subject: Re: [SC-L] Where Does Secure Coding
 Belong In the Curriculum?
 
 On Tue, Aug 25, 2009 at 7:26 AM, Goertzel, Karen 
 [USA]goertzel_ka...@bah.com wrote:
 For consistency's sake, I hope you agree that if security is an
 intermediate-to-advanced concept in software development, then all
 the other -ilities (goodness properties, if you will), such as
 quality, reliability, usability, safety, etc. that go beyond just
 get the bloody thing to work are also intermediate-to-advanced
 concepts.
 
 In other words, teach the goodness properties to developers only
 after they've inculcated all the bad habits they possibly can, and
 then, when they are out in the marketplace and never again
 incentivised to actually unlearn those bad habits, TRY desperately
 to change their minds using nothing but F.U.D. and various other
 psychological means of dubious effectiveness.
 
 Seriously?  We're going to teach kids in 5th grade who are just 
 learning what an algorithm is how to protect against malicious
 inputs, how to make their application fast, handle all exception
 conditions, etc?
 
 ...
 

-- 
Benjamin Tomhave, MS, CISSP
fal...@secureconsulting.net
Blog: http://www.secureconsulting.net/
Twitter: http://twitter.com/falconsview
Photos: http://photos.secureconsulting.net/
Web: http://falcon.secureconsulting.net/
LI: http://www.linkedin.com/in/btomhave

[ Random Quote: ]
That which has always been accepted by everyone, everywhere, is almost
certain to be false.
Paul Valery
___
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] Where Does Secure Coding Belong In the Curriculum?

2009-08-26 Thread Benjamin Tomhave
Matt Bishop wrote:
 
 And that's an artifact of a lack of resources for the type of grading.
 Give classes the support to do this, and I suspect you'd see people get
 in the habit of writing better code. Better, use students and people
 from industry who know this stuff to staff a clinic analogous to a
 writing clinic for English and law schools -- that would reinforce it
 not just for the students, but for the clinic staff as well.
 
This sounds like an excellent extension for OWASP. :)

-ben

-- 
Benjamin Tomhave, MS, CISSP
fal...@secureconsulting.net
Blog: http://www.secureconsulting.net/
Twitter: http://twitter.com/falconsview
Photos: http://photos.secureconsulting.net/
Web: http://falcon.secureconsulting.net/
LI: http://www.linkedin.com/in/btomhave

[ Random Quote: ]
I hope if dogs ever take over the world and they choose a king, they
don't just go by size, because I bet there are some Chihuahuas with some
good ideas.
Deep Thoughts by Jack Handy
___
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] Cigital news (European market)

2009-05-19 Thread Benjamin Tomhave
Kenneth Van Wyk wrote:
 But I just don't get the feeling that they're trying in any way to
 align themselves with the US market.  They'll do their own thing in
 their own time, which is as it should be.
 
That syncs with my limited experience with Europeans, both in the past
(the French in particular) and in the present (Dutch). Any suggestion
that Europe will follow the US is probably an error in judgment and
highly likely to offend. We should never forget that we're a mere 233
years old independently compared to their several centuries. The Roman
Empire lasted almost twice that long.

-ben

-- 
Benjamin Tomhave, MS, CISSP
fal...@secureconsulting.net
LI: http://www.linkedin.com/in/btomhave
Blog: http://www.secureconsulting.net/
Photos: http://photos.secureconsulting.net/
Web: http://falcon.secureconsulting.net/

[ Random Quote: ]
Perfection is not attainable, but if we chase perfection we can catch
excellence.
Vince Lombardi
___
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] Announcing LAMN: Legion Against Meaningless certificatioNs

2009-03-22 Thread Benjamin Tomhave
fwiw, I've interviewed my fair share of CISSPs who didn't have a basic
understanding of infosec... with the boot camps these days, people don't
learn anything... they cram for 1-2 wks, shoving everything into
short-term rote memory, and then they take the test and promptly forget
everything... this is especially true since the feds began mandating
CISSPs for contractors... at least here in the DC metro, the pool of
candidates has become extremely watered down over the last 5 or so years...

Joe Teff wrote:
 I notice certs like CISSP when hiring. It says the person has a basic
 understanding of all IS security areas. Nothing more. If someone can't
 pass the CISSP then I have to wonder why.
 
 -Original Message-
 From: Paco Hope p...@cigital.com
 To: SC-L@securecoding.org SC-L@securecoding.org
 Date: Thu, 19 Mar 2009 11:36:45 -0400
 Subject: Re: [SC-L] Announcing LAMN: Legion Against Meaningless
 certificatioNs
 
 On 3/18/09 5:29 PM, Jeremy Epstein jeremy.j.epst...@gmail.com wrote:
 
  If you don't have a CISSP, CISM, MCSE, or EIEIO - and you're proud
 of it
 
 ...then I'd say you have an overly simplistic view of the world.
 
 Anyone who believes that a credential automatically conveys some magical
 knowledge that you didn't have before is just as overly-simplistic as
 someone who disparages all credentials equally. It just isn't a
 black and
 white world.
 
 Paco
 -- 
 Paco Hope, CISSP, CSSLP
 Technical Manager, Cigital, Inc
 http://www.cigital.com/ ? +1.703.585.7868
 Software Confidence. Achieved.
 
 
 ___
 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.
 ___
 
 
 
 
 ___
 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.
 ___

-- 
Benjamin Tomhave, MS, CISSP
fal...@secureconsulting.net
LI: http://www.linkedin.com/in/btomhave
Blog: http://www.secureconsulting.net/
Photos: http://photos.secureconsulting.net/
Web: http://falcon.secureconsulting.net/

[ Random Quote: ]
I think there should be something in science called the 'reindeer
effect.' I don't know what it would be, but I think it'd be good to hear
someone say, 'Gentlemen, what we have here is a terrifying example of
the reindeer effect.'
Deep Thoughts by Jack Handy
___
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] BSIMM: Confessions of a Software Security Alchemist(informIT)

2009-03-20 Thread Benjamin Tomhave
I would argue that the security 'bugs' you've described are in fact
functional deficiencies in the implemented design. That is, the exploit
of them has a direct impact on functional performance of the
application, even if it's just a problem with error handling (input
validation).

I would further argue that treating security as a special case ends up
doing us more harm than good. Doing so allows developers, designers, and
the business to shrug it off as Somebody Else's Problem (SEP), instead
of owning it themselves. The same goes for the requirements, design, etc.

As an industry, we've developed segments of specialized knowledge, and
then have the audacity to complain about it not being mainstream. It's
time we picked one, and I would argue that mainstreaming these concepts
will be far more effective than continuing as a specialized bolt-on
discipline (which is not to say that specialized research should not
occur, just that in real life the application of this knowledge should
not be specialized, per se).

*shrug* The only way I see to win the game is to change the rules and/or
the game play itself. We must never forget that the security industry
still relies (heavily) on many of the same concepts that protected us 15
years ago (i.e. signature-based scans and ACLs - AV+firewall).

-ben

Goertzel, Karen [USA] wrote:
 No - that isn't really what I meant. There CAN be security bugs -
 i.e., implementation errors with direct security implications, such
 as a divide-by-zero error that allows a denial of service in a
 security-critical component, thus exposing what is supposed to be
 protected data.
 
 But there are also bad security decisions - these can be at the
 requirements spec or design spec level. If they're at the
 requirements spec level, they aren't bugs - they are either
 omissions of good security or commissions of bad security. An
 omission of good security is not encrypting a password. That isn't a
 bug per se - unless it's a violation of policy. But if there's no
 password encryption policy, then the failure to include a requirement
 to encrypt passwords would not be a bug or a violation of any sort
 (except a violation of common sense). It would still, however, result
 in poor security.
 
 -- Karen Mercedes Goertzel, CISSP Booz Allen Hamilton 703.698.7454 
 goertzel_ka...@bah.com
 
 
 
 
 -Original Message- From: Benjamin Tomhave
 [mailto:list-s...@secureconsulting.net] Sent: Fri 20-Mar-09 11:04 To:
 Goertzel, Karen [USA] Cc: Secure Code Mailing List Subject: Re:
 [SC-L] BSIMM: Confessions of a Software Security Alchemist(informIT)
 
 So, what you're saying is that security bugs are really design
 flaws, assuming a perfect implementation of the design. Ergo,
 security bug is at best a misnomer, and at worst a fatal deficiency
 in design acumen.
 
 :)
 
 -ben
 
 Goertzel, Karen [USA] wrote:
 Except when they're hardware bugs. :)
 
 I think the differentiation is also meaningful in this regard: I
 can specify software that does non-secure things. I can implement
 that software 100% correctly. Ipso facto - no software bugs. But
 the fact remains that the software doesn't validate input because I
 didn't specify it to validate input, or it doesn't encrypt
 passwords because I didn't specify it to do so. I built to spec; it
 just happened to be a stupid spec. So the spec is flawed - but the
 implemented software conforms to that stupid spec 100%, so by
 definition it not flawed. It is, however, non-secure.
 
 -- Karen Mercedes Goertzel, CISSP Booz Allen Hamilton 703.698.7454 
 goertzel_ka...@bah.com
 
 
 
 
 -Original Message- From: sc-l-boun...@securecoding.org on
 behalf of Benjamin Tomhave Sent: Thu 19-Mar-09 19:28 To: Secure
 Code Mailing List Subject: Re: [SC-L] BSIMM: Confessions of a
 Software Security Alchemist(informIT)
 
 Why are we differentiating between software and security bugs?
 It seems to me that all bugs are software bugs, ...
 
 

-- 
Benjamin Tomhave, MS, CISSP
fal...@secureconsulting.net
LI: http://www.linkedin.com/in/btomhave
Blog: http://www.secureconsulting.net/
Photos: http://photos.secureconsulting.net/
Web: http://falcon.secureconsulting.net/

[ Random Quote: ]
Hofstadter's Law: A task always takes longer than you expect, even when
you take into account Hofstadter's Law.
http://globalnerdy.com/2007/07/18/laws-of-software-development/
___
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] BSIMM: Confessions of a Software Security Alchemist(informIT)

2009-03-20 Thread Benjamin Tomhave
So, what you're saying is that security bugs are really design flaws,
assuming a perfect implementation of the design. Ergo, security bug is
at best a misnomer, and at worst a fatal deficiency in design acumen.

:)

-ben

Goertzel, Karen [USA] wrote:
 Except when they're hardware bugs. :)
 
 I think the differentiation is also meaningful in this regard: I can
 specify software that does non-secure things. I can implement that
 software 100% correctly. Ipso facto - no software bugs. But the fact
 remains that the software doesn't validate input because I didn't
 specify it to validate input, or it doesn't encrypt passwords because I
 didn't specify it to do so. I built to spec; it just happened to be a
 stupid spec. So the spec is flawed - but the implemented software
 conforms to that stupid spec 100%, so by definition it not flawed. It
 is, however, non-secure.
 
 --
 Karen Mercedes Goertzel, CISSP
 Booz Allen Hamilton
 703.698.7454
 goertzel_ka...@bah.com
 
 
 
 
 -Original Message-
 From: sc-l-boun...@securecoding.org on behalf of Benjamin Tomhave
 Sent: Thu 19-Mar-09 19:28
 To: Secure Code Mailing List
 Subject: Re: [SC-L] BSIMM: Confessions of a Software Security
 Alchemist(informIT)
 
 Why are we differentiating between software and security bugs? It
 seems to me that all bugs are software bugs, ...
 

-- 
Benjamin Tomhave, MS, CISSP
fal...@secureconsulting.net
LI: http://www.linkedin.com/in/btomhave
Blog: http://www.secureconsulting.net/
Photos: http://photos.secureconsulting.net/
Web: http://falcon.secureconsulting.net/

[ Random Quote: ]
Hartree's Law: Whatever the state of a project, the time a
project-leader will estimate for completion is constant.
http://globalnerdy.com/2007/07/18/laws-of-software-development/
___
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] Announcing LAMN: Legion Against Meaningless certificatioNs

2009-03-19 Thread Benjamin Tomhave
gee whiz, what if you have letters after your name that aren't
meaningless certifications (like MS or PhD)? :)

also, what if you have meaningless cert letters after your name, but
only because of peer pressure? are we still allowed to join? :)

Jeremy Epstein wrote:
 Colleagues,
 
 I'm pleased to announce the creation of LAMN, the Legion Against
 Meaningless certificatioNs.  If you don't have a CISSP, CISM, MCSE, or
 EIEIO - and you're proud of it - this group is for you. 
 
 You can join LAMN on LinkedIn by searching in the groups area.  Unlike
 so many other certifications, LAMN doesn't charge fees, require
 outrageously overpriced exams, or demand check-the-box continuing education.
 
 Hope to see many people joining this group - and feel free to pass this
 along!
 --Jeremy
 
 P.S. After you join the group, you can proudly write your name John
 Doe, LAMN - which conveniently also stands for Letters After My Name. 
 I can't recall who suggested the term to me, but would be happy to give
 credit if someone wants to step forward and claim credit.
 
 
 
 
 ___
 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.
 ___
-- 
Benjamin Tomhave, MS, CISSP
fal...@secureconsulting.net
LI: http://www.linkedin.com/in/btomhave
Blog: http://www.secureconsulting.net/
Photos: http://photos.secureconsulting.net/
Web: http://falcon.secureconsulting.net/

[ Random Quote: ]
Dusting is a good example of the futility of trying to put things
right. As soon as you dust, the fact of your next dusting has already
been established.
George Carlin
___
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] Positive impact of an SSG

2009-03-11 Thread Benjamin Tomhave
.
 
 Those gains are exclusively the result of having mature and
 effective controls within our system and software development
 lifecycle, Routh says. This is a three-year-old initiative that
 educates and certifies developers in all DTCC environments in
 security. Developers are also provided with the necessary
 code-scanning tools and consulting and services help to keep
 production code close to pristine.
 
 --Sammy.
 
 Sammy Migues Principal, Technology 703.404.5830 -
 http://www.cigital.com Software confidence. Achieved. 
 smig...@cigital.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
  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. 
 ___
 
 
 
 

-- 
Benjamin Tomhave, MS, CISSP
fal...@secureconsulting.net
LI: http://www.linkedin.com/in/btomhave
Blog: http://www.secureconsulting.net/
Photos: http://photos.secureconsulting.net/
Web: http://falcon.secureconsulting.net/

[ Random Quote: ]
Don't you wish there were a knob on the TV to turn up the intelligence?
There's one marked 'Brightness,' but it doesn't work.
Gallagher
___
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] Positive impact of an SSG

2009-03-11 Thread Benjamin Tomhave
 either that or go back to making stuff up.
 
 BTW, I checked the BSIMM web site after I read your message.  It worked
 for me.  Try this?
 http://www.downforeveryoneorjustme.com/bsi-mm.com
 
 Brian
 
 On 3/11/09 10:48 AM, Benjamin Tomhave list-s...@secureconsulting.net
 wrote:
 
 I think it's an interesting leap of faith. Statistically speaking, 9 is
 a very small sample size. Thus, the proposed model will be viewed
 skeptically until it is validated with a much larger and more diverse
 sample. Putting it another way, there's no way I can take this to a
 small or medium sized org and have them see immediate relevance, because
 their first reaction is going to be those are 9 large orgs with lots of
 resources - we don't have that luxury.
 
 You quoted we can say with confidence that these activities are
 commonly found in highly successful programs - how do you define a
 highly successful program? What's the rule or metric? Is this a rule
 or metric that can be genericized easily to all development teams?
 
 My concern is exactly what you speculate about... organizations are
 going to look at this and either try to tackle everything (and fail) or
 decide there's too much to tackle (and quit). In my experience working
 with maturity models as a consultant, very few people actually
 understand the concept. Folks are far more tuned-in to a PCI-like
 prescriptive method. Ironically, the PCI folks say the same thing you
 did - that it's not meant to be prescriptive, that it's supposed to be
 based on risk management practices - yet look how it's used.
 
 Maybe you've addressed this, but it doesn't sound like it. I'd perhaps
 be better educated here if the web site wasn't down... ;)
 
 -ben
 
 Sammy Migues wrote:
  Hi Pravir,
 
  Thanks for clarifying what you're positing. I'm not sure how we could
  have been more clear in the BSIMM text accompanying the exposition of
  the collective activities about the need to take this information and
  work it into your own culture (i.e., do risk management). As a few
  examples:
 
  p. 3: BSIMM is meant as a guide for building and evolving a software
  security initiative. As you will see when you familiarize yourself
  with the BSIMM activities, instilling software security into an
  organization takes careful planning and always involves broad
  organizational change. By clearly noting objectives and goals and by
  tracking practices with metrics tailored to your own initiative, you
  can methodically build software security in to your organization’s
  software development practices.
 
  p. 47: Choosing which of the 110 BSIMM activities to adopt and in
  what order can be a challenge. We suggest creating a software
  security initiative strategy and plan by focusing on goals and
  objectives first and letting the activities select themselves.
  Creating a timeline for rollout is often very useful. Of course
  learning from experience is also a good strategy.
 
  p. 47: Of the 110 possible activities in BSIMM, there are ten
  activities that all of the nine programs we studied carry out. Though
  we can’t directly conclude that these ten activities are necessary
  for all software security initiatives, we can say with confidence
  that these activities are commonly found in highly successful
  programs. This suggests that if you are working on an initiative of
  your own, you should consider these ten activities particularly
  carefully (not to mention the other 100).
 
  p. 48: The chart below shows how many of the nine organizations we
  studied have adopted various activities. Though you can use this as a
  rough “weighting” of activities by prevalence, a software security
  initiative plan is best approached through goals and objectives.
 
  Your words (...BSIMM fails...) imply (to me) that you posit
  organizations attempting to use the collected wisdom in BSIMM will,
  inexplicably, look at it and say Okay, we have to do all 110 of
  these things exactly as written, so let's get started without regard
  to their local need. This is as opposed to, say, looking at it and
  thinking Here's what nine companies have spent dozens of
  person-decades and millions of dollars learning about what works;
  let's see what we can glean from that. Uh, okay.
 
  Yes, previous models exist. Although it may have come up in
  conversation, we did not ask any of the nine something like What
  model did you start with back in the beginning? because it simply
  isn't relevant to what we're trying to accomplish (documenting what
  successful organizations are doing), just as could and should
  aren't relevant. We asked What *are* you doing now? and documented
  it so others could

[SC-L] Wysopal says tipping point reached...

2008-11-04 Thread Benjamin Tomhave
An interesting read. Not much to really argue with, I don't think.
http://www.veracode.com/blog/2008/11/we%e2%80%99ve-reached-the-application-security-tipping-point/

-- 
Benjamin Tomhave, MS, CISSP
[EMAIL PROTECTED]
LI: http://www.linkedin.com/in/btomhave
Blog: http://www.secureconsulting.net/
Photos: http://photos.secureconsulting.net/
Web: http://falcon.secureconsulting.net/

[ Random Quote: ]
Anticipate the difficult by managing the easy.
Lao Tzu
___
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.
___


[SC-L] 0x000000.com SuiGenchi Demonstration

2008-03-16 Thread Benjamin Tomhave
Has anybody had opportunity to look at this tool for PHP source code 
analysis? Just wondering about the relative merits vs other tools 
already available.
http://www.0x00.com/?i=530

-- 
Benjamin Tomhave, MS, CISSP
[EMAIL PROTECTED]
LI: http://www.linkedin.com/in/btomhave
Blog: http://www.secureconsulting.net/
Photos: http://photos.secureconsulting.net/
Web: http://falcon.secureconsulting.net/

[ Random Quote: ]
Think off-center.
George Carlin
___
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] quick question - SXSW

2008-03-12 Thread Benjamin Tomhave
First, thanks for that Bill, it exemplifies my point perfectly. A couple 
thoughts...

one, targeting designers is just as important as reaching out to the 
developers themselves... if the designers can ensure that security 
requirements are incorporated from the outset, then we receive an added 
benefit...

two, a re-phrasing around my original thought... somehow we need to get 
security thinking and considerations encoded into the DNA of everyone in 
the business, whether they be designers, architects, coders, analysts, 
PMs, sysadmins, etc, etc, etc. Every one of those topics you mention 
could (should!) have had implicit and explicit security attributes 
included... yet we're still at the point where secure coding has to be 
explicitly requested/demanded (often as an afterthought or bolt-on)...

How do we as infosec professionals get people to the next phase of 
including security thoughts in everything they do... with the end-goal 
being that it is then integrated fully into practices and processes as a 
bona fide genetic mutation that is passed along to future generations?

To me, this seems to be where infosec is stuck as an industry. There 
seems to be a need for a catalyst to spur the mutation so that it can 
have a life of its own. :)

fwiw.

-ben

-- 
Benjamin Tomhave, MS, CISSP
[EMAIL PROTECTED]
LI: http://www.linkedin.com/in/btomhave
Blog: http://www.secureconsulting.net/
Photos: http://photos.secureconsulting.net/
Web: http://falcon.secureconsulting.net/

[ Random Quote: ]
Augustine's Second Law of Socioscience: For every scientific (or 
engineering) action, there is an equal and opposite social reaction.
http://globalnerdy.com/2007/07/18/laws-of-software-development/

William L. Anderson wrote:
 Dear Ben, having just been at SXSW Interactive (I live in Austin, TX) I 
 did not see many discussions that pay attention to security, or any 
 other software engineering oriented concerns, explicitly.
 
 There was a discussion of scalability for web services that featured the 
 developers from digg, Flickr, WordPress, and Media Temple. I got there 
 about half-way through but the discussion with the audience was about 
 tools and methods to handle high traffic loads. There was a question 
 about build and deployment strategies and I asked about unit testing 
 (mixed answers - some love it, some think it's strong-arm micro-mgt (go 
 figure)).
 
 There was a session on OpenID and OAuth (open authorization) standards 
 and implementation. These discussions kind of assume the use of secure 
 transports but since I couldn't stay the whole time I don't know if 
 secure coding was addressed explicitly.
 
 The main developer attendees at SXSW would call themselves designers and 
 I would guess many of them are doing web development in PHP, Ruby, etc. 
 I think the majority of attendees would not classify themselves as 
 software programmers.
 
 To me it seems very much like at craft culture. That doesn't mean that a 
 track on how to develop secure web services wouldn't be popular. In fact 
 it might be worth proposing one for next year.
 
 If you want to talk further, please get in touch.
 
 -Bill Anderson
 praxis101.com
 
 Benjamin Tomhave wrote:
 I had just a quick query for everyone out there, with an attached 
 thought.

 How many security and/or secure coding professionals are prevalently
 involved with the SXSW conference this week? I know, I know... it's a big
 party for developers - particularly the Web 2.0 clique - but I'm just
 curious.

 Here's why: I'm increasingly frustrated by the disconnect between
 business/dev and security. I don't feel like we're being largely
 successful in getting the business and developers to include security as
 part of their standard operating procedures. Developers are still
 oftentimes lazy and sloppy, creating XSS and CSRF and SQL injection 
 holes.

 I then look at SXSW from afar and think: a) shouldn't I be there
 evangelizing security? and, b) shouldn't a major thread to all these
 conferences be about how security is integrating with dev processes and
 practices, making it better?

 Maybe I'm just too idealist. I'm curious what everyone else thinks.

 cheers,

 -ben

 
 

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


[SC-L] quick question - SXSW

2008-03-11 Thread Benjamin Tomhave
I had just a quick query for everyone out there, with an attached thought.

How many security and/or secure coding professionals are prevalently
involved with the SXSW conference this week? I know, I know... it's a big
party for developers - particularly the Web 2.0 clique - but I'm just
curious.

Here's why: I'm increasingly frustrated by the disconnect between
business/dev and security. I don't feel like we're being largely
successful in getting the business and developers to include security as
part of their standard operating procedures. Developers are still
oftentimes lazy and sloppy, creating XSS and CSRF and SQL injection holes.

I then look at SXSW from afar and think: a) shouldn't I be there
evangelizing security? and, b) shouldn't a major thread to all these
conferences be about how security is integrating with dev processes and
practices, making it better?

Maybe I'm just too idealist. I'm curious what everyone else thinks.

cheers,

-ben

-- 
Benjamin Tomhave, MS, CISSP
[EMAIL PROTECTED]
LI: http://www.linkedin.com/in/btomhave
Blog: http://www.secureconsulting.net/
Photos: http://photos.secureconsulting.net/
Web: http://falcon.secureconsulting.net/

In answer to the question of why it happened, I offer the modest proposal
that our Universe is simply one of those things which happen from time to
time.
Edward P. Tryon


___
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] PCI: Boon or bust for software security?

2008-03-04 Thread Benjamin Tomhave
Worse than that, I think that until businesses universally understand the
value of secure coding practices, they will resist the up-front cost to
take on such a transformational program.

SOX vs PCI would make for a good case study. SOX is very high level and
generic, which led to much confusion and wasted money initially. Some orgs
were able to leverage it for the first year or two to drive improved
security practices, but it seems that, for the most part, this leverage is
gone.

PCI, on the other hand, is for the most part quite specific (despite some
ambiguity due to poor writing quality). It has primarily resulted in a
checklist-oriented approach to compliance and has not seemingly led to
transformational change, but rather many spot fixes. While it is still
usable to leverage organizations, and it has moved the needle a little bit
in terms of baseline security practices, overall I'd put it's effect on
par with SOX.

Thus, you have two sets of regulations that used very different
approaches, but with very similar results: relative ineffectiveness. For
me, this raises the question, Can regulation be used to stimulate the
business to undertake transformational change to adopt and integrate
holistic, pervasive security practices?

The problem, I think, is that PCI is too easily relegated by the business
to IT. This can be the case because PCI is technically specific. SOX, on
the other hand, was not specific enough, and so eventually became almost
dismissable by the business, eventually with minimal involvement from IT
(perhaps a gross oversimplification). The key, then, seems to be in trying
to construct requirements that will stick with the business instead of
being easily delegated. Perhaps something risk-oriented would have the
desired effect...

fwiw.

-ben

-- 
Benjamin Tomhave, MS, CISSP
[EMAIL PROTECTED]
LI: http://www.linkedin.com/in/btomhave
Blog: http://www.secureconsulting.net/
Photos: http://photos.secureconsulting.net/
Web: http://falcon.secureconsulting.net/

In answer to the question of why it happened, I offer the modest proposal
that our Universe is simply one of those things which happen from time to
time.
Edward P. Tryon
On Tue, March 4, 2008 09:02, Andy Murren wrote:
 Overall I concur with Bruce on this.  PCI has too broad of a
 constituent base to cover to be truly effective.  Some fixes were
 added after the TJX  breach, but look at how much TJX paid versus how
 much the laid aside to pay.  I am betting that the TJX lawyers
 produced documents showing that they were PCI compliant, and that Visa
 had accepted the annual findings.  In the end TJX was able to claim
 that they were not negligent because they were PCI compliant.  While
 PCI 1.1 points to OWASP for in house developed web applications, where
 are the standards for 'PCI Approved' vendor development?  How secure
 is the development process at the middleware vendor that is part of
 that web app, how good are the standards those organizations use and
 are held to?

 I think until there is an industry wide generally accepts, and pushed,
 standard for integrating secure development into the SDLC we will see
 band aid approaches like the updated PCI.

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




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


[SC-L] a little coding humor...

2008-02-05 Thread Benjamin Tomhave
A little something to make you smile... infosec fellow for MS Mark 
Curphy posted an amusing cartoon to his blog on code review:
http://securitybuddha.com/2008/02/06/funny-code-review-cartoon/

cheers,

-ben

-- 
Benjamin Tomhave, MS, CISSP
[EMAIL PROTECTED]
LI: http://www.linkedin.com/in/btomhave
Blog: http://www.secureconsulting.net/
Photos: http://photos.secureconsulting.net/
Web: http://falcon.secureconsulting.net/

[ Random Quote: ]
The Law of False Alerts: As the rate of erroneous alerts increases, 
operator reliance, or belief, in subsequent warnings decreases.
http://globalnerdy.com/2007/07/18/laws-of-software-development/
___
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.
___


[SC-L] XKCD on sane build environments

2008-01-16 Thread Benjamin Tomhave
A little something to make you smile... :)
http://xkcd.com/371/

-- 
Benjamin Tomhave, MS, CISSP
[EMAIL PROTECTED]
Web: http://falcon.secureconsulting.net/
LI: http://www.linkedin.com/in/btomhave
Blog: http://www.secureconsulting.net/
Photos: http://photos.secureconsulting.net/

[ Random Quote: ]
Marge: Homer! There's someone here who can help you...
Homer: Is it Batman?
Marge: No, he's a scientist.
Homer: Batman's a scientist?!
Marge: It's not Batman!
___
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] OWASP Publicity

2007-11-19 Thread Benjamin Tomhave
James,

You misunderstood my comments wrt older technologies. My points were:
1) We should not expect people rooted in older technology contexts to
naturally understand problems in modern technology contexts if their jobs
have not required them to evolve their thinking.
2) In trying to effectively communicate challenges to these business
leaders, it may be useful to understand their context and provide
correlated examples in the context they understand, rather than stubbornly
insisting that they update their context. As people age, change becomes
increasingly difficult to handle (this is a truth of psychology and
neuroscience), so we should not assume that they will be able to easily
adjust their context. As responsible security professionals, we should
find a way to bridge the gap, getting the same points across in language
that they'll understand.

The other point made was that there continues to be a disconnect with
business leaders in that they seem fine making business decisions, but
then panic when it becomes an IT decision. The point here is that we
should be extremely diligent in casting IT/security decisions as business
decisions and reassuring them that the thought processes are the same. The
only potential downfall is that it then puts additional responsibilities
on our security shoulders to make sure we've presented the business risk
analysis adequately to properly support a risk decision.

Lastly, yes, I agree it's a red flag when execs meddle in the affairs of
techies, but it happens a lot, and we should be prepared for dealing with
it. This problem becomes especially challenging in light of #1 above,
wherein their context is tied to outmoded technologies and the associated
ways of thinking. This does _not_ mean we should limit our options to
those outmoded technologies, but that we need to be cognizant of the
limited thought context and provide adequate explanation that is
_understood_ when challenging what is happening and providing
alternatives.

cheers,

-ben

-- 
Benjamin Tomhave, MS, CISSP
[EMAIL PROTECTED]
Web: http://falcon.secureconsulting.net/
LI: http://www.linkedin.com/in/btomhave
Blog: http://www.secureconsulting.net/
Photos: http://photos.secureconsulting.net/

We must scrupulously guard the civil liberties of all citizens, whatever
their background. We must remember that any oppression, any injustice, any
hatred is a wedge designed to attack our civilization.
-President Franklin Delano Roosevelt

On Mon, November 19, 2007 11:00 am, James Stibbards wrote:
 Ben,

 Good comments.  It may be true that older technology is what today's Sr
 Managers have the most familiarity with, however... In my opinion, it's
 not
 that familiarity that we (or they) should rely on, in order to be
 well-informed, and thus be making good security-related decisions. It's no
 longer their job to be into the details of that technology, unless they
 are
 the CTO (for example), and if they are into the details... That's actually
 a
 red flag to me that they're likely *not* doing their actual job, today, as
 a
 Sr. Manager.  [Slight rant: It *is* the responsibility of the management
 team of the organization, overall, to be sure that information which is
 critical to the organization be conveyed, abstracted or not, up and down
 the
 layers of the entire omanagement and individual contributors... to
 accomplish whatever organizational goals exist. (see more, below).]

 If a Sr Manager was once familiar with COBOL (I chuckled at the recent
 COBOL
 SC-L postings...), but the issues are now WinMobile and AJAX, then it's
 really the responsibility of someone in the organzation to have
 synthesized
 and presented  the security issues, opportunities, and costs as they
 relate
 to WinMobile/AJAX/etc. to senior management as Business Issues. At other
 layers in the organization, yes, there are Technology issues, concerns,
 joy
 and grief... But not at the Executive levels, because that's not their
 job(!).

 As an aside...since security means so many things to so many people, here
 is
 a 4-layer model that I use with a lot of my customer to help position what
 we do, in the vast landscape of security:

  1. Business/Mission objectives - what are we trying to accomplish?
  2. Systems Architecture - how is this being instantiated, in terms of
 systems, communication, storage, etc?
  3. Security Architecture - what specific technology and processes are we
 using to reduce risk, introduce control mechanisms, etc.
  4. Protection Technology - how do we lock down the #3, so it can be
 resistant to attack, itself.

 I've used this over and over again, in helping to frame discussions of
 what
 should or could be done, so that they're not confusing.  For example,
 a
 question of policy with a question of choice of technology selection.

 A few days early, but Happy Thanksgiving, to all!

 - James

 James W. Stibbards
 Sr. Director - Sales Engineering
 Cloakware, Inc.
 email: [EMAIL PROTECTED]
 phone: 703-752-4836
 cell: 571

Re: [SC-L] OWASP Publicity

2007-11-18 Thread Benjamin Tomhave
I agree and disagree with these comments, as I think they possibly
represent an outmoded way of thinking when it comes to IT management.
Execs and senior mgmt _must_ have a certain understanding of security
that will at least give them a basis for making risk decisions. It seems
today that they are fine (generally) making business risk decisions, but
then believe falsely that making an IT risk decision requires following
a completely different set of rules (when, in fact, it's just another
kind of business risk decision). I'm of the belief that this directly
correlates to their lack of fundamental understanding of IT and security
issues.

Where I agree is the level of detail that needs to be imparted. OWASP
Top 10 is probably too much detail to communicate to the average exec or
sr manager. However, we must not overlook that these business leaders
were once individual contributors. Yes, it's true that some of these
folks came up through a strictly business route, but for the most part
these days I see these careers originating in at least a semi-technical
role. We should be seeking to leverage those backgrounds to educate them
and bring them to modern times.

On Crispin's later comments about bad vs good managers, I think he's
very much hit the nail on the head (see the quote in my sig). However,
there's one aspect that's overlooked, which is outdated prior history.
If an executive's understanding of technology is founded in their first
contributions as an individual contributor 10-20 years ago, then this
means their understanding of modern technology may be severely limited.
I'm sure all of us understand how difficult it is to stay on top of
current trends as technology evolves, and it's often our job to do so.
What if it's not your job to keep current? The times will change while
your focus is elsewhere, but only a truly savvy person will think to
check that context before making decisions that affect it. This seems to
be a rarity.

So, to conclude, I think that it would be valuable, in broad brush
strokes, to educate leaders about secure coding - and security in
general - but perhaps not to the level of detail we might really desire
to see. We want execs and sr managers to drive their folks toward secure
coding practices, but that doesn't mean they themselves have to know how
to code securely. As such, in targeting these other publications, the
message should be refined to be business-oriented, extolling the
business risks associated with ignoring these practices and providing a
big arrow pointing in the direct of orgs like OWASP.

fwiw.

-ben

-- 
Benjamin Tomhave, MS, CISSP
[EMAIL PROTECTED]
Web: http://falcon.secureconsulting.net/
LI: http://www.linkedin.com/in/btomhave
Blog: http://www.secureconsulting.net/
Photos: http://photos.secureconsulting.net/

[ Random Quote: ]
If a man is offered a fact which goes against his instincts, he will
scrutinize it closely, and unless the evidence is overwhelming, he will
refuse to believe it. If, on the other hand, he is offered something
which affords a reason for acting in accordance to his instincts, he
will accept it even on the slightest evidence. The origin of myths is
explained in this way.
Bertrand Russell

Crispin Cowan wrote:
 McGovern, James F (HTSC, IT) wrote:
 I have observed an interesting behavior in that the vast majority of IT
 executives still haven't heard about the principles behind secure
 coding. My take says that we are publishing information in all the wrong
 places. IT executives don't really read ACM, IEEE or other the sporadic
 posting from bloggers but they do read CIO, Wall Street Journal and most
 importantly listen to each other.

 What do folks on this list think about asking the magazines and
 newspapers to publish? I am willing to gather contact information of
 news reporters and others within the media if others are willing to
 amplify the call to action in terms of contacting them. 
   
 The vast majority of IT executives are unfamiliar with all of the
 principles of security, firewalls, coding, whatever.
 
 The important thing to understand is that such principles are below
 their granularity; then are *right* to not care about such principles,
 because they can't do anything about them. Their granularity of decision
 making is which products to buy, which strategies to adopt, which
 managers to hire and fire. Suppose they did understand the principles of
 secure coding; how then would they use that to decide between firewalls?
 Web servers? Application servers?
 
 If anything, the idea that needs to be pitched to IT executives is to
 pay more attention to quality than to shiny buttons  features. But
 there's the rub, what is quality and how can an IT executive measure it?
 
 I have lots of informal metrics that I use to measure quality, but they
 largely amount to synthesized reputation capital, derived from reading
 bugtraq and the like with respect to how many vulnerabilities I see with
 respect to a given product, e.g

[SC-L] [Fwd: Seeking questions for Panel discussion on website vulnerability disclosure during OWASP-WASC AppSec Conference on Nov 15]

2007-11-07 Thread Benjamin Tomhave
Forwarding with permission... please send feedback directly to Anurag as
he is not currently a member of this list.

-ben

-- 
[ Random Quote: ]
Cyberspace. A consensual hallucination experienced daily by billions of
legitimate operators, in every nation, by children being taught
mathematical concepts.
William Gibson

 Original Message 
Subject: Seeking questions for Panel discussion on website vulnerability
disclosure during OWASP-WASC AppSec Conference on Nov 15
Resent-Date: Tue,  6 Nov 2007 09:57:45 -0700 (MST)
Resent-From: [EMAIL PROTECTED]
Date: Mon, 5 Nov 2007 16:46:51 -0800
From: Anurag Agarwal [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
References:
[EMAIL PROTECTED]

I am not sure if everyone knows about the panel discussion on Website
Vulnerability Disclosure during the OWASP-WASC AppSec Conference on Nov
15. I will be moderating that panel and wanted this to be an honest
discussion between a hacker, a corporate and govt. I know there was an
email thread few days ago on Full disclosure of security vulnerabilities
so i thought i will send this to the list as well. I am interested in
knowing what people would like to know or what questions they would like
them to discuss on. you can find the details of the panelists and other
stuff on the following posting.

http://myappsecurity.blogspot.com/2007/11/panel-discussion-on-website.html

Feel free to send in questions (i dont care how crazy, inciting or
provocative it is). You can send it to me directly or post as a comment
on my blog or if the moderator of the mailing lists dont mind then reply
to the list.


Cheers,

Anurag Agarwal
Blog: http://myappsecurity.blogspot.com
Email: [EMAIL PROTECTED]
Web: www.myappsecurity.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
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.
___


[SC-L] Bernstein's new paper on secure coding

2007-11-06 Thread Benjamin Tomhave
Daniel J Bernstein, author of the qmail MTA, has written an interesting,
short paper on qmail security and the secure coding practices that went
into it. I imagine folks here will find it of interest, too.
http://cr.yp.to/qmail/qmailsec-20071101.pdf

-- 
Benjamin Tomhave, MS, CISSP
[EMAIL PROTECTED]
Web: http://falcon.secureconsulting.net/
LI: http://www.linkedin.com/in/btomhave
Blog: http://www.secureconsulting.net/
Photos: http://photos.secureconsulting.net/

We must scrupulously guard the civil liberties of all citizens, whatever
their background. We must remember that any oppression, any injustice, any
hatred is a wedge designed to attack our civilization.
-President Franklin Delano Roosevelt

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


[SC-L] Sw Dev Laws, Engineers and Feasibility

2007-08-13 Thread Benjamin Tomhave
Ok, rather late in posting these, but thought it might help you get your
week off to a good start.  The first link is a list of laws of software
development.  You've undoubtedly heard of many of them, but it's still nice
to have a single place of reference for them.  Especially when faced with
making arguments against silly projects.  Speaking of which, I've also added
a second link below that is somewhat tongue-in-cheek defining what certain
key terms mean to engineers with respect to feasibility of projects.
Enjoy! :)

Laws of Software Development
http://globalnerdy.com/2007/07/18/laws-of-software-development/

Understanding Engineers: Feasibility
http://fishbowl.pastiche.org/2007/07/17/understanding_engineers_feasibility

cheers,

-ben

--
Benjamin Tomhave, MS, CISSP
[EMAIL PROTECTED]
Web: http://falcon.secureconsulting.net/
LI: http://www.linkedin.com/in/btomhave
Blog: http://www.secureconsulting.net/
Photos: http://photos.secureconsulting.net/

We must scrupulously guard the civil rights and civil liberties of all
citizens, whatever their background. We must remember that any oppression,
any injustice, any hatred is a wedge designed to attack our civilization.
-President Franklin Delano Roosevelt

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


[SC-L] author contends CompSci != Maths

2007-07-09 Thread Benjamin Tomhave
Caught this on /. this morning, maybe you did, too.  Pretty interesting
reading, really.  The fundamental argument is that algorithms are
inadequately expressive to suit CompSci today.  If you look at all the
attempts in 3GL, 4GL, 5GL and beyond to be more expressive, and if you've
ever listened to Donal Knuth speak, you might start tending to agree with
the argument.  What do you think?
http://www.itwire.com.au/content/view/13339/53/

---
Benjamin Tomhave, MS, CISSP, NSA-IAM, NSA-IEM
[EMAIL PROTECTED]
Web: http://falcon.secureconsulting.net/
LI: http://www.linkedin.com/in/btomhave
Blog: http://www.secureconsulting.net/
Photos: http://photos.secureconsulting.net/

We must scrupulously guard the civil rights and civil liberties of all
citizens, whatever their background. We must remember that any oppression,
any injustice, any hatred is a wedge designed to attack our civilization.
-President Franklin Delano Roosevelt

___
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] Technology-specific Security Standards

2007-05-23 Thread Benjamin Tomhave
In my experience, a tiered approach is useful.  The higher up you are in the
policy framework, the more general and time-enduring the content should be.
The farther you progress down the framework to a more detailed level, the
more perishable the content will be, out of necessity.  The reason that
we've adopted specific guidance bound at the technical level is because
implementers need it.  They're not security experts (usually) and do not
necessarily grok security the same way a seasoned (salty?) security person
might.

A couple colleagues and I actually chatted about this around the same time
that the original message here is timestamped, in the context of application
security standards.  The approach we're planning to adopt is to provide
good, minimally-specific guidance in our formal standards documents (e.g.
implement input validation) and the produce living implementation guides
(possibly in a wiki form) that can be referenced in relation to the
standards.  We'll see how this works in reality, but it seems to be a nice
mix in theory between provide specific requirements without getting so far
into the weeds that it will require constant rewriting as the underlying
technologies change.

fwiw.

-ben

---
Benjamin Tomhave, MS, CISSP, NSA-IAM, NSA-IEM
[EMAIL PROTECTED]
Web: http://falcon.secureconsulting.net/
LI: http://www.linkedin.com/in/btomhave
Blog: http://www.secureconsulting.net/
Photos: http://photos.secureconsulting.net/

We must scrupulously guard the civil rights and civil liberties of all
citizens, whatever their background. We must remember that any oppression,
any injustice, any hatred is a wedge designed to attack our civilization.
-President Franklin Delano Roosevelt
 

 -Original Message-
 From: [EMAIL PROTECTED] 
 [mailto:[EMAIL PROTECTED] On Behalf Of John Steven
 Sent: Wednesday, May 23, 2007 2:39 PM
 To: SC-L@securecoding.org
 Subject: [SC-L] Technology-specific Security Standards
 
 All,
 
 My last two posts to Cigital's blog covered whether or not to 
 build your security standards specific to a technology-stack 
 and code-centric or to be more general about them:
 
 http://www.cigital.com/justiceleague/2007/05/18/security-guida
 nce-and-its-%e
 2%80%9cspecificity-knob%e2%80%9d/
 
 And
 
 http://www.cigital.com/justiceleague/2007/05/21/how-to-write-g
 ood-security-g
 uidance/
 
 Dave posted a comment on the topic, which I'm quoting here:
 -
 Your point about the ³perishability² of such prescriptive 
 checklists does make the adoption of such a program fairly 
 high maintenance. Nothing wrong with that, but expectations 
 should be set early that this would not be a fire and forget 
 type of program, but rather an ongoing investment.
 -
 
 I agree, specifying guidance at this level does take a lot 
 more effort; you get what you pay for eh? I responded in turn 
 with a comment of my own. I've seen some organizations 
 control this cost effectively and still get value:
 
 See:
 http://www.cigital.com/justiceleague/2007/05/18/security-guida
 nce-and-its-%e
 2%80%9cspecificity-knob%e2%80%9d/#comment-1048
 
 Some people think my stand controversial...
 
 What do you guys think?
 
 
 John Steven
 Technical Director; Principal, Software Security Group
 Direct: (703) 404-5726 Cell: (703) 727-4034 Key fingerprint = 
 4772 F7F3 1019 4668 62AD  94B0 AE7F EEF4 62D5 F908
 
 Blog: http://www.cigital.com/justiceleague
 Papers: http://www.cigital.com/papers/jsteven
 
 http://www.cigital.com
 Software Confidence. Achieved.
 
 
 ___
 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.
 ___
 


___
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 defines an InfoSec Professional?

2007-03-09 Thread Benjamin Tomhave
I'm gonna have to go ahead and disagree with you, there, Michael.  You're
looking at things far too narrowly.  And here's a very simple example:

Small business.  Single DMZ.  Hosts DB and Web App on separate platforms. 
Web app needs to make back-end calls to DB.  There's no reason whatsoever
why the DB itself needs to be directly exposed to the Internet.  Thus, you
implement a firewall that restricts ingress access on ports 80/443 to the
web server only.

This scenario would exist irregardless of the quality of the underlying
code, based on principles of default deny, defense in depth, segregation
of duties, etc.  In other words, don't put all your eggs in the securely
coded basket.

---
On the original topic... I don't think titles or certifications or even
security-related actions make a security professional.  I know personnel
within security departments who perform access management tasks without a
solid understanding of what all is contained within infosec.  They don't
know the security triad (C-I-A), they don't necessarily have a sound
understanding of why they're doing what they do, etc.  Yet they have
security in their titles.

Similarly, I've interviewed many a CISSP who I would not consider to be an
infosec professional.  Just because you can memorize a few facts within
the 10 infosec domains does not mean you get it.  I would even go so far
as to say that just because a developer reads the OWASP Top 10 and then
begins performing input validation does not make them an infosec
professional.  It makes them a better developer.

Bottom line, then, is that a true infosec professional should be defined
as someone working in a dedicated security role who distinguishes
themselves by their level of knowledge, wisdom, and experience that can be
demonstrably applied within the infosec genre.

fwiw  tgif.

cheers,

-ben

-- 
Benjamin Tomhave, MS, CISSP, NSA-IAM, NSA-IEM
[EMAIL PROTECTED]
Web: http://falcon.secureconsulting.net/
LI: http://www.linkedin.com/profile?viewProfile=key=1539292
Blog: http://www.secureconsulting.net/
Photos: http://photos.secureconsulting.net/

We must scrupulously guard the civil liberties of all citizens, whatever
their background. We must remember that any oppression, any injustice, any
hatred is a wedge designed to attack our civilization.
-President Franklin Delano Roosevelt

On Fri, March 9, 2007 7:54 am, Michael S Hines wrote:
 I respectfully disagree.

 The need for a firewall or IDS is due to the poor coding of the receptor
 of
 network traffic - so you have to prevent bad things from reaching the
 receptor (which is the TCP/IP stack and then the host operating system -
 and
 then the middleware and then the application).

 The reason you have to prevent bad things from reaching the receptor (OS)
 is
 because of poor coding practices in the receptor (OS).

 In terms of state diagrams - you have an undefied state in the code -
 which
 produces unpredictable actions.  Technically speaking, it's undesireable
 but
 predictable actions - that's how the software can be used to gain
 unauthorized entry.  And once someone finds the hole - the very mechanism
 used for protection (networks) is used to spread the story.  Kind of like
 the farmer eating his seed corn.   :)

 Regarding roles - there are many who do Infosec - in many different roles.
 Law makers, lawyers, Boards of Directors, management, policy staff,
 technical staff, network engineers, programmers, quality assurance staff,
 users, ethical hackers, unethical hackers, et al.

 I'm not sure we're moving the industry forward by trying to say I am one
 but You are not - are we?

 Mike Hines
 -
 Michael S Hines
 [EMAIL PROTECTED]


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



___
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] differences between Threat Analysis and Threat Modeling

2007-02-14 Thread Benjamin Tomhave
Jason,
 
I differentiate between the two like this:
 
Threat Analysis looks at specific threats (e.g., msblaster, zotob, latest
exploit of pick your fav sw/os).
Threat Modeling looks at classes of threats (e.g., network-distributed
malware, OS vulnerabilities of Type).
 
Threat analysis is used as a component to various assessment techniques
(vulnerability scanning, code review, etc.).  The aggregation of data from
multiple threat analyses within a define class of threat can then be used to
develop a model of that threat.  Threat modeling can then be used to look at
the overall security and resilience of a system, instead of focusing on the
minutae of every individual threat.  Ergo, foci on anti-virus, OS hardening,
patch management, etc.  Practices developed in response to the modeling of
classes of threats, the models for which were developed from analysis of the
threats that resulted in their classification.
 
Or something like that...
 
cheers,
 
-ben

---
Benjamin Tomhave, CISSP, NSA-IAM, NSA-IEM
[EMAIL PROTECTED]
Web: http://falcon.secureconsulting.net/
LI: http://www.linkedin.com/profile?viewProfile=
http://www.linkedin.com/profile?viewProfile=key=1539292 key=1539292
Blog: http://www.secureconsulting.net/
Photos: http://photos.secureconsulting.net/

We must scrupulously guard the civil rights and civil liberties of all
citizens, whatever their background. We must remember that any oppression,
any injustice, any hatred is a wedge designed to attack our civilization.
-President Franklin Delano Roosevelt


 


  _  

From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of Jason Grembi
Sent: Wednesday, February 14, 2007 4:12 PM
To: sc-l@securecoding.org
Subject: [SC-L] differences between Threat Analysis and Threat Modeling


Hi Ken, 

I am currently researching the differences between Threat Analysis and
Threat Modeling. 

I thought your readers on the mailing list may give me a clearer
distinction.

 

How I understand it is that both identify security threats, determine risk,
and create the right countermeasures by analyzing various types of
documentation about the system and looking for vulnerabilities and/or areas
of weakness. 

 

Threat Analysis - is more informal way of 'eyeballing' system architecture
and application design.

Threat Modeling [Microsoft SDL] - more formal, every requirement is modeled
and scrutinized.
 
Any additional help you or your readers can provide would be appreciated.
 

Thanks

Jason Grembi

Web Developer



___
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] WEB2.0 Security Issues

2007-01-28 Thread Benjamin Tomhave
 as an agitator? This is not to say that there aren't
potential benefits, particularly in terms of unlocking the long tail to
market better to consumers. It just provides the start of the slippery slope
argument. We need keep in mind the need to balance civil liberties against
universal trackability. Why does privacy need to be an illusion?

(*Note: A special thanks to my friend Bob Alberti of Sanction, Inc., for
proof-reading and providing input on this posting.)

---
Benjamin Tomhave, CISSP, NSA-IAM, NSA-IEM
[EMAIL PROTECTED]
Web: http://falcon.secureconsulting.net/
LI: http://www.linkedin.com/pub/0/622/964
Blog: http://www.secureconsulting.net/
Photos: http://photos.secureconsulting.net/

We must scrupulously guard the civil rights and civil liberties of all
citizens, whatever their background. We must remember that any oppression,
any injustice, any hatred is a wedge designed to attack our civilization.
-President Franklin Delano Roosevelt


 




From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Avi Shvartz
Sent: Thursday, January 25, 2007 2:06 AM
To: sc-l@securecoding.org
Subject: [SC-L] WEB2.0 Security Issues




Hello list,

Lately I read some articles that cover WEB2.0 from various aspects
(social, technical etc.).

What I am missing is a reference to security  privacy issues
related to WEB2.0.

I would like to hear opinions what are the new security  privacy
concerns that WEB2.0 

Creates and if possible, links to relevant resources 

Thanks,

Avi


___
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] Vulnerability tallies surged in 2006 | The Register

2007-01-22 Thread Benjamin Tomhave
This is completely unsurprising.  Apparently nobody told the agile dev
community that they still need to follow all the secure coding practices
preached at the traditional dev folks for eons.  XSS, redirects, and SQL
injection attacks are not revolutionary, are not all that interesting, and
are so common-place that it makes one wonder where these developers have
been the last 5-10 years.
 
Solution to date: throw out traditional design review, move to agile
security testing.  Why?  Because there seems rarely to be a design to
review, and certainly no time to do it in.  Overall, it's important that
agile apps be built on an underlying publishing framework so that inherited
vulns can be found and fixed across the board by focusing on a single
platform.
 
Next challenge: new year, new technology fads.  Web 2.0 is another code word
for that's so last year.  Time to play catch-up, and January isn't over
yet! *sigh*  Oh, and speaking of Web 2.0, who's protecting the customer and
their data?  Better yet, who owns which data?  With mashups being the buzz
word du jour, you may think your data is on SiteA, when in fact it's spread
across SiteB, SiteC, and SiteD.  Wheee.
 
One bit of good news: agile dev has often meant, in my experience, rapid
resolution of discovered vulns.  Since you don't have the full SDLC (or
comparable) process to follow, or even a formalized patch mgmt process, it's
often just a matter of finding bugs (through targeted hyper-testing -
think flash-bang), sending them to the devies, waiting 10-30 minutes, and
watching the vuln disappear like magic.  Am curious how change mgmt works on
that, though... ;)
 
cheers,
 
-ben

---
Benjamin Tomhave, CISSP, NSA-IAM, NSA-IEM
[EMAIL PROTECTED]
Web: http://falcon.secureconsulting.net/
LI: http://www.linkedin.com/pub/0/622/964
Blog: http://www.secureconsulting.net/

We must scrupulously guard the civil rights and civil liberties of all
citizens, whatever their background. We must remember that any oppression,
any injustice, any hatred is a wedge designed to attack our civilization.
-President Franklin Delano Roosevelt


 


  _  

From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of Kenneth Van Wyk
Sent: Monday, January 22, 2007 1:24 PM
To: Secure Coding
Subject: [SC-L] Vulnerability tallies surged in 2006 | The Register


FYI, CERT/CC reported 8064 software vulnerabilities in 2006, for a 35%
increase over 2005.

See http://www.theregister.co.uk/2007/01/21/2006_vulns_tally/ 

The article further states, The greatest factor in the skyrocketing number
of vulnerabilities is that certain types of flaws in community and
commercial Web applications have become much easier to find, said Art
Manion, vulnerability team lead for the CERT Coordination Center. 

'The best we can figure, most of the growth is due to fairly
easy-to-discover vulnerabilities in Web applications, Manion said. They
are easy to find, easy to create, and easy to deploy.'

Cheers,

Ken

-
Kenneth R. van Wyk
SC-L Moderator
KRvW Associates, LLC
http://www.KRvW.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
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.
___