Re: [SC-L] [External] Re: SearchSecurity: Dynamism

[Goertzel, Karen [USA]]

Yes, we seem to abandon security mechanisms that (1) we can actually trust, and 
(2) that Microsoft and Google refuse to build.

===
Karen Mercedes Goertzel, CISSP, CSSLP
Senior Lead Scientist
Booz Allen Hamilton
703.698.7454
goertzel_ka...@bah.com

"The hardest thing of all is to
find a black cat in a dark room,
especially if there is no cat."
- Confucius



From: Peter G. Neumann [neum...@csl.sri.com]
Sent: 06 September 2015 15:24
To: Goertzel, Karen [USA]
Cc: Alfonso De Gregorio; Johan Peeters; Secure Code Mailing List
Subject: Re: [SC-L] [External] Re: SearchSecurity: Dynamism

Reference monitors were a lovely concept, largely invented for multilevel
security kernels and trusted computing bases, but are almost nonexistent
in that context.  Yes, they'd be lovely to have, but even the NSA folks
seem to have abandoned them...

___
Secure Coding mailing list (SC-L) SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php
SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.
Follow KRvW Associates on Twitter at: http://twitter.com/KRvW_Associates
___

Re: [SC-L] [External] Re: SearchSecurity: Dynamism

[Goertzel, Karen [USA]]

It's been there since Windows NT 4.0, and is used with mandatory integrity 
labels to enforce a mandatory integrity policy so that subjects with a lower 
integrity label cannot access (and, most importantly, cannot modify) objects 
with higher integrity labels. 

It also exists separate from the Windows DAC ACL, which is what seems to govern 
user access to data files. One gets the impression it is intended to be used to 
protect DLL executables against modification by unauthorized processes, which 
is a worthy usage, but doesn't do anything for sensitivity- or privacy-based 
control of information flow.



===
Karen Mercedes Goertzel, CISSP, CSSLP
Senior Lead Scientist
Booz Allen Hamilton
703.698.7454
goertzel_ka...@bah.com

"The hardest thing of all is to
find a black cat in a dark room,
especially if there is no cat."
- Confucius



From: Gary McGraw [g...@cigital.com]
Sent: 08 September 2015 15:44
To: Goertzel, Karen [USA]; Peter G. Neumann
Cc: Secure Code Mailing List
Subject: Re: [SC-L] [External] Re: SearchSecurity: Dynamism

As far as I know, Microsoft integrated some reference monitoring into their OS 
family under Fred Schneider’s guidance.  They called it “inline reference 
monitoring” and I believe they still use it.

gem




On 9/8/15, 8:49 AM, "SC-L on behalf of Goertzel, Karen [USA]" 
<sc-l-boun...@securecoding.org on behalf of goertzel_ka...@bah.com> wrote:

>Yes, we seem to abandon security mechanisms that (1) we can actually trust, 
>and (2) that Microsoft and Google refuse to build.
>
>===
>Karen Mercedes Goertzel, CISSP, CSSLP
>Senior Lead Scientist
>Booz Allen Hamilton
>703.698.7454
>goertzel_ka...@bah.com
>
>"The hardest thing of all is to
>find a black cat in a dark room,
>especially if there is no cat."
>- Confucius
>
>
>
>From: Peter G. Neumann [neum...@csl.sri.com]
>Sent: 06 September 2015 15:24
>To: Goertzel, Karen [USA]
>Cc: Alfonso De Gregorio; Johan Peeters; Secure Code Mailing List
>Subject: Re: [SC-L] [External] Re: SearchSecurity: Dynamism
>
>Reference monitors were a lovely concept, largely invented for multilevel
>security kernels and trusted computing bases, but are almost nonexistent
>in that context.  Yes, they'd be lovely to have, but even the NSA folks
>seem to have abandoned them...
>
>___
>Secure Coding mailing list (SC-L) SC-L@securecoding.org
>List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
>List charter available at - http://www.securecoding.org/list/charter.php
>SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
>as a free, non-commercial service to the software security community.
>Follow KRvW Associates on Twitter at: http://twitter.com/KRvW_Associates
>___

___
Secure Coding mailing list (SC-L) SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php
SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.
Follow KRvW Associates on Twitter at: http://twitter.com/KRvW_Associates
___

Re: [SC-L] [External] Re: SearchSecurity: Dynamism

[Goertzel, Karen [USA]]

Does anyone else remember "reference monitors"?

What an old-fashioned idea. But they'd certainly solve a lot of problems.

===
Karen Mercedes Goertzel, CISSP, CSSLP
Senior Lead Scientist
Booz Allen Hamilton
703.698.7454
goertzel_ka...@bah.com

"The hardest thing of all is to
find a black cat in a dark room,
especially if there is no cat."
- Confucius



From: SC-L [sc-l-boun...@securecoding.org] on behalf of Alfonso De Gregorio 
[a...@secyoure.com]
Sent: 28 August 2015 13:02
To: Johan Peeters
Cc: Secure Code Mailing List
Subject: [External]  Re: [SC-L] SearchSecurity: Dynamism

On Thu, Aug 20, 2015 at 8:20 PM, Johan Peeters  wrote:
> nice one, Gary. Finally something positive about agile and DevOps. A
> trick that you may have missed is immutable servers, see Docker and
> friends. They will be a leap forward for server security when they hit
> the mainstream.

Immutable servers are nice -- let's deploy them. Yet, in an execution
environment where code is data and data is code, high assurance
software will also require control-flow integrity in the face of
malicious input. Or, what we would be left with are weird machines
instantiated from disposable images.

-- Alfonso
___
Secure Coding mailing list (SC-L) SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php
SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.
Follow KRvW Associates on Twitter at: http://twitter.com/KRvW_Associates
___

___
Secure Coding mailing list (SC-L) SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php
SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.
Follow KRvW Associates on Twitter at: http://twitter.com/KRvW_Associates
___

Re: [SC-L] [External] Re: SearchSecurity: Medical Devices and Software Security

[Goertzel, Karen [USA]]

Another big frustration: No-one seems to be making any real headway into the 
problem of actually measuring loss attributable to doing nothing - or, in other 
words, losses cradle to grave from operating insufficiently secure systems. 
People try to measure ROI from security, which is a ridiculous concept 
because it involves trying to measure a negative - i.e., this is how many times 
we DIDN'T lose $n - can't be done - or trying to measure how much competitive 
advantage only being hacked 20 vs. 50 times last year gave us as a company - or 
other such silly pseudo-measurements.

What I really want is:

[1] Ability to measure the aggregate of losses attributable to a single 
degradation or failure in an ICT infrastructure (all layers) - not just 
immediate loss due to downtime or degraded performance, but all the costs 
involved in redirecting resources (i.e., to deal with incident response, 
forensics, restoring from backup, implementing COOP, etc.); implementing 
interim short and long-term workarounds, purchases and man-hours involved in 
achieving total recovery to a sustained acceptable working state (ideally the 
same or better state than pre-loss); investment in preemptiove actions, things, 
and extraordinary (not what I was already doing) risk management activities to 
prevent a recurrence; plus all the other things I've probably not thought of 
here that contribute to the WHOLE amount of loss (e.g., reputation loss, 
advertising and PR reputation recovery campaigns, legal fees, fines, 
preparations plus actual expenses involved in testifying in court and/or on 
Capitol Hill, !
 additional tests and audits needed, etc.);

[2] Ability to accurately determine which of my ICT-related losses can be 
attributed, in whole or in part (and, in the latter case, what %) to 
intentional malevolent actions by someone (direct or via supply chain or 
operational subversion or sabotage via malware, etc.) - and which losses can be 
attributed to stupid mistakes by someone.

Once I can get a real grip on actual, complete loss amounts - not just the 
stuff that usually gets measured - I can then see if I really have struck the 
right balance between what I spend on security to avoid/prevent loss, and what 
I'm actually losing - so I can figure out if I need to adjust the equation. 
Also, being able to accurately identify all the someones involved in causing 
each loss - e.g., developers, integrators, users, administrators, etc. - while 
this level of attribution isn't necessary to quantify losses - would enable me 
not only to figure out if I'm spending the right amount, but if I'm spending 
the right amount on the right things. For example, if my losses are mainly down 
to crappy or subverted software, investment in mitigating end-user risk is 
going to be of less value than investment in correcting SLDC deficiencies.

In short, every time I read about a new attempt to measure security, it's 
always either too granular or not granular enough, and I'm not seeing any 
credible efforts to apply analysis across all measurement data to actually 
build a COMPLETE picture not only of the current security situation, but of 
the whole cost of security - what it is, and more importantly, what it should 
be.

===
Karen Mercedes Goertzel, CISSP
Senior Lead Scientist
Booz Allen Hamilton
703.698.7454
goertzel_ka...@bah.com

Answers are easy. It's asking the right questions which is hard.
- The Doctor


From: Jeffrey Walton [noloa...@gmail.com]
Sent: 07 July 2014 14:56
To: Goertzel, Karen [USA]
Cc: Secure Code Mailing List
Subject: Re: [SC-L] [External] Re: SearchSecurity: Medical Devices and Software 
Security

 Ever since I read an article about the challenges of remote laser surgery 
 being done by doctors at the Naval Hospital in Bethesda, MD, via satellite 
 link on wounded soldiers in Iraq, I've been warning for years about the need 
 to apply software assurance principles to the development and testing - and 
 SCRM to the acquisition - of medical devices and their embedded software.

https://en.wikipedia.org/wiki/Therac-25 FTW!

 What I want to know is this: When is someone who can actually make a 
 difference going to FINALLY figure out the real potential hazards of the 
 Internet of Things.

+1. Dr. Geer has already warned about it at
http://www.lawfareblog.com/2014/04/heartbleed-as-metaphor/. Can you
imagine the IoT, with medical devices and avionics packages, running
around with little to no testing and little more that the browser
security model. Clear the cache to erase the evidence!!!

 Manufacturers of the latter need to stop trying so bloody hard to improve 
 products that no longer need improvement.

This is a political problem rooted in software liability laws (or lack
thereof). Too many carrots, not enough sticks

As it stands, its cost effective to do nothing. The risk analysis
equations need to be tipped in favor of the consumer or user. One it
starts costing

Re: [SC-L] [External] Firewalls, Fairy Dust, and Forensics

[Goertzel, Karen [USA]]

The one point that's missing from the article is to remind people: What the 
heck do you think firewalls are made of? Software! So unless a software 
manufacturer has got software security religion, their product is just as 
likely to be broken inside than the things it allegedly protects. 

===
Karen Mercedes Goertzel, CISSP
Lead Associate
Booz Allen Hamilton
703.698.7454
goertzel_ka...@bah.com

I love humans. Always seeing patterns in things that aren't there.
- The Doctor


From: SC-L [sc-l-boun...@securecoding.org] on behalf of Gary McGraw 
[g...@cigital.com]
Sent: 31 March 2014 18:40
To: Secure Code Mailing List
Subject: [External]  [SC-L] Firewalls, Fairy Dust, and Forensics

hi sc-l,

Ever get discouraged that we have not been making enough progress in software 
security?  Well, we have been making plenty of progress and our field is 
growing fast!   This peppy little article (co-authored with Sammy Migues) 
explains why firewalls, fairy dust, and forensics are not working out for 
computer security.

Oh, and software security is growing at 20% CAGR and now accounts for 10% of 
the computer security market (which is itself growing at 8.9%).  We are in the 
right field, and the this mailing list is a major help.

Please read this: 
http://searchsecurity.techtarget.com/opinion/McGraw-Firewalls-fairy-dust-and-forensics-Try-software-security
  Then have your SSG members read it.  You do have an SSG, right?

Feel free to post links to twitter, facebook, linkedin, and send it around (by 
pointer).  I would really appreciate that.

Thanks!

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.
Follow KRvW Associates on Twitter at: http://twitter.com/KRvW_Associates
___

___
Secure Coding mailing list (SC-L) SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php
SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.
Follow KRvW Associates on Twitter at: http://twitter.com/KRvW_Associates
___

Re: [SC-L] [External] Re: Sad state of affairs

[Goertzel, Karen [USA]]

I agree that ONE end goal of software security is to safeguard data - but it is 
not the only goal...and may not even be the primary goal, depending on the type 
of system the software is part of. In a safety-critical system, safeguard the 
data takes on a very different meaning from what one thinks of in a typical 
information system. Yes, I may in fact be trying to safeguard input sent from 
logical or physical sensors so that the data can't be tampered with in a way 
that can threaten the safe operation of the system. But safeguarding the data 
in that case is only a means to an end - the main goal is to prevent someone 
from intentionally exploiting a flaw in the software in order to instigate a 
physical failure that could threaten health, lives, the environment, etc. 

===
Karen Mercedes Goertzel, CISSP
Lead Associate
Booz Allen Hamilton
703.698.7454
goertzel_ka...@bah.com

If you're not failing every now and again,
it's a sign you're not doing anything very innovative.
- Woody Allen


From: sc-l-boun...@securecoding.org [sc-l-boun...@securecoding.org] on behalf 
of Jeffrey Walton [noloa...@gmail.com]
Sent: 21 September 2013 00:24
To: Rafal Los
Cc: Secure Coding List; Bobby G. Miller
Subject: [External]  Re: [SC-L] Sad state of affairs

On Fri, Sep 20, 2013 at 11:34 PM, Rafal Los ra...@ishackingyou.com wrote:

 Wait a minute, this relationship is a bit confused I think. Prasad said it 
 well- often the result of a maturing software security program is that the 
 simple and easy bugs disappear and the ones that are left are difficult to 
 find and complex in exploitation.

 This is known as eliminating the low hanging fruit. While this doesn't 
 eliminate ALL bugs, I ultimately believe that's a fools' errand anyway. 
 Making the software as free of bugs as possible necessarily makes the ones 
 left in the system difficult to find and exploit. Then you work in good 
 anomaly detection mechanisms and have a great case for *reasonably* secure 
 software.

Well, the end goal of software security is to safe guard the data. All
a bad guy wants to do is collect, egress and monetize the data (sans
National Security concerns). If the data is not safe, then the
definition of reasonable has problems.

Consider: I was part of two breaches. The one in the 1990's cost me
about $10,000 to fix (I found out after I was sued). The second was in
New York last summer that cost me $75 to fix (have a card re-issued
and shipped next-day service).

If you ask the companies involved if their processes were reasonable,
they would probably say YES. After all, the companies followed best
practices, minimized their losses and maximized their profits. If you
ask me, I would say NO.

Picking low hanging fruit is not enough. Ironically, we're not even
doing that very well (as BM noted). If you don't agree, take some time
to cruise ftp.gnu,org and look at the state of those projects (and its
not just free software). But I consider it a failure of security
professionals since its our job to educate developers and improve
their processes.*

 Of course, this is all predicated on you knowing and being able to define the 
 word reasonable.
:)

 Just my opinion.
And my jaded opinion :)

Jeff

* There's some hand waiving here since some (many?) argue its a waste
of time and money to teach developers; and the money is better spent
on building tools that make it hard/difficult to do things incorrectly
in the first place. I kind of think its a mixture of both.

 - Reply message -
 From: Jeffrey Walton noloa...@gmail.com
 To: Bobby G. Miller b.g.mil...@gmail.com
 Cc: Secure Coding List sc-l@securecoding.org
 Subject: [SC-L] Sad state of affairs
 Date: Fri, Sep 20, 2013 10:01 PM


 On Fri, Sep 20, 2013 at 7:47 PM, Bobby G. Miller b.g.mil...@gmail.com wrote:
 I was just listening to a podcast interviewing a security executive from a
 prominent vendor.  The response to vulnerabilities was to raise the
 cost/complexity of exploiting bugs rather than actually employing secure
 coding practices.  What saddened me most was that the approach was
 apparently effective enough.
 +1. Software security is in a sad state. What I've observed: let the
 developers deliver something, then have it pen tested, and finally fix
 what the pen testers find. I call it catch me if you can security.

 I think the underlying problem is the risk analysis equations. Its
 still cost effective to do little or nothing. Those risk analysis
 equations need to be unbalanced.

 And I don't believe this is the solution:
 http://searchsecurity.techtarget.com/opinion/Congress-should-encourage-bug-fixes-reward-secure-systems.
 Too many carrots and too few sticks means it becomes more profitable
 to continue business as usual.

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

Re: [SC-L] [External] Sad state of affairs

[Goertzel, Karen [USA]]

On the other hand, isn't it somewhat analagous to hiring 24/7 armed security 
guards and installing a state of the art physical security system in a museum, 
and passing and enforcing strict laws against grand larceny?

The secure coding alternative would be for museums to stop displaying 
priceless art works.

===
Karen Mercedes Goertzel, CISSP
Lead Associate
Booz Allen Hamilton
703.698.7454
goertzel_ka...@bah.com

If you're not failing every now and again,
it's a sign you're not doing anything very innovative.
- Woody Allen

From: sc-l-boun...@securecoding.org [sc-l-boun...@securecoding.org] on behalf 
of Bobby G. Miller [b.g.mil...@gmail.com]
Sent: 20 September 2013 19:47
To: sc-l@securecoding.org
Subject: [External] [SC-L] Sad state of affairs

I was just listening to a podcast interviewing a security executive from a 
prominent vendor.  The response to vulnerabilities was to raise the 
cost/complexity of exploiting bugs rather than actually employing secure coding 
practices.  What saddened me most was that the approach was apparently 
effective enough.

___
Secure Coding mailing list (SC-L) SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php
SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.
Follow KRvW Associates on Twitter at: http://twitter.com/KRvW_Associates
___

Re: [SC-L] [External] Chinese Hacking, Mandiant and Cyber War

[Goertzel, Karen [USA]]

I agree - and grow increasingly frustrated with those who insist on confusing 
cyber war with cyber espionage (and vice versa). But I've found it's quite 
easy to get them to understand the difference by simply asking them to drop the 
prefix cyber from each. Cyber war is simply war fought on an electronic 
battlefield with digital weapons. The general objectives are the same as 
physical warfare: disable/destroy the adversary's capabilities. 

In cyber espionage, by contrast, the objective is to obtain information that is 
held secret by the adversary. This said, espionage is never an end in itself - 
information must be used for something to have any value. Thus the (possible) 
source of confusion (other than that pesky cyber tag): one may undertake 
cyber espionage in aid of cyber war - just as one sends out spies to learn 
secrets to give one's side a strategic advantage in warfare (or soldiers to do 
reconnaissance before battle - which is a form of tactical espionage). 

The problem is that the origin of the cyber attacks involved may be the same, 
and the timing of the cyber attacks may be (near) simultaneous, so that in the 
heat of the moment, one might be forgiven for misconstruing as cyber war what 
is in fact cyber espionage in aid of cyber war. But as the objectives of the 
two are quite different, the attack patterns are also very likely to be 
different. So there is no excuse for anyone with more than the most superficial 
level of understanding of things cyber to confuse one with the other. 

===
Karen Mercedes Goertzel, CISSP
Lead Associate
Booz Allen Hamilton
703.698.7454
goertzel_ka...@bah.com

If you're not failing every now and again,
it's a sign you're not doing anything very innovative.
- Woody Allen


From: sc-l-boun...@securecoding.org [sc-l-boun...@securecoding.org] on behalf 
of Gary McGraw [g...@cigital.com]
Sent: 20 February 2013 09:34
To: Secure Code Mailing List
Cc: Bruce Schneier; Ross Anderson
Subject: [External]  [SC-L] Chinese Hacking, Mandiant and Cyber War

hi sc-l,

No doubt all of you have seen the NY Times article about the Mandiant report 
that pervades the news this week.  I believe it is important to understand the 
difference between cyber espionage and cyber war.  Because espionage unfolds 
over months or years in realtime, we can triangulate the origin of an 
exfiltration attack with some certainty.  During the fog of a real cyber war 
attack, which is more likely to happen in milliseconds,  the kind of forensic 
work that Mandiant did would not be possible.  (In fact, we might just well be 
Gandalfed and pin the attack on the wrong enemy as explained here: 
http://searchsecurity.techtarget.com/news/2240169976/Gary-McGraw-Proactive-defense-prudent-alternative-to-cyberwarfare.)

Sadly, policymakers seem to think we have completely solved the attribution 
problem.  We have not.  This article published in Computerworld does an 
adequate job of stating my position: 
http://news.idg.no/cw/art.cfm?id=94AB4F98-9BBD-1370-154D49FAA7706BE9

Those of us who work on security engineering and software security can help 
educate policymakers and others so that we don't end up pursuing the folly of 
active defense.

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.
Follow KRvW Associates on Twitter at: http://twitter.com/KRvW_Associates
___

___
Secure Coding mailing list (SC-L) SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php
SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.
Follow KRvW Associates on Twitter at: http://twitter.com/KRvW_Associates
___

[SC-L] Won't it be great if they can finally make survivable software-intensive systems a reality?

[Goertzel, Karen [USA]]

http://www.newscientist.com/article/mg21729045.400-the-computer-that-never-crashes.html

===
Karen Mercedes Goertzel, CISSP
Lead Associate
Booz Allen Hamilton
703.698.7454
goertzel_ka...@bah.com

If you're not failing every now and again,
it's a sign you're not doing anything very innovative.
- 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
___

Re: [SC-L] Re (badware vs. goodware): SearchSecurity: Badware versus malware

[Goertzel, Karen [USA]]

Agent software is all well and good. 

But if you secretly implant the agents, and design them to be undetectable, and 
do not inform the intended user of the system that they are there, they are 
spyware - and at best, unethical. And, by my definition at least, unethical = 
bad. 


===
Karen Mercedes Goertzel, CISSP
Lead Associate
Booz Allen Hamilton
703.698.7454
goertzel_ka...@bah.com

I love deadlines. I like the whooshing sound they make as they fly by.
- Douglas Adams


From: brunn...@informatik.uni-hamburg.de [brunn...@informatik.uni-hamburg.de]
Sent: 13 May 2012 04:17
To: sc-l@securecoding.org
Cc: Goertzel, Karen [USA]; Peter G. Neumann; Gary McGraw
Subject: Re (badware vs. goodware): [SC-L] SearchSecurity: Badware versus 
malware

Karen, whereas flaws and defects can hardly be argued to have possibly
some good affects, there have been many controversial arguments whether
some malware (aka viruses) may have beneficial effects and may
therefore be regarded as sort of goodware. Indeed, I vividly remember a
controversial debate with Fred Cohen at a MITI-invited conference in
Tokyo (in the 1990s) whether viruses may be used for beneficial purposes
(e.g. implanting automagically some security measures). My counter
argument that good intentions of authors must be explicitly communicated
to users (aka usees as their system is used without their knowledge
and agreement) was not shared by the esteemed colleague, and I also
remember controversial discussions at our lab (VTC of Hamburg university)
with Vesselin Bontchev about aspects of good viruses :-)

My 2 cents: nobody will (hopefully) doubt that badware is bad, whereas
some may regard some badware to have good (aka beneficial) effects.

Best wishes: Klaus (May 13, 2012)

Zitat von Goertzel, Karen [USA] goertzel_ka...@bah.com:

 In other words, flaws and defects caused through developer error,
 ignorance, negligence etc. can be exploited to cause harm. So even
 if one could prevent actual intentional malicious inclusions in
 software, one hasn't eliminated the problem of exploitable flawed
 logic.

 The megachallenge, of course, is looking for what one doesn't
 actually know is there. Which is why software security testing is so
  hard.

 ===
 Karen Mercedes Goertzel, CISSP
 Lead Associate
 Booz Allen Hamilton
 703.698.7454
 goertzel_ka...@bah.com

 I love deadlines. I like the whooshing sound they make as they fly by.
 - Douglas Adams

 
 From: sc-l-boun...@securecoding.org [sc-l-boun...@securecoding.org]
 on behalf of Peter G. Neumann [neum...@csl.sri.com]
 Sent: 08 May 2012 11:30
 To: Gary McGraw
 Cc: Secure Code Mailing List
 Subject: Re: [SC-L] SearchSecurity: Badware versus malware

 The differences are marginal.
 What's worse, bad software or malicious software? ...

 My book has a pervasive theme:
   Many things that could happen accidentally could be triggered
 intentionally.
   Many things that happen intentionally could be triggered accidentally.

 Trying to reduce one without the other may be foolhardy in most realistic
 threat models.

 ___
 Secure Coding mailing list (SC-L) SC-L@securecoding.org
 List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
 List charter available at - http://www.securecoding.org/list/charter.php
 SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
 as a free, non-commercial service to the software security community.
 Follow KRvW Associates on Twitter at: http://twitter.com/KRvW_Associates
 ___

 ___
 Secure Coding mailing list (SC-L) SC-L@securecoding.org
 List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
 List charter available at - http://www.securecoding.org/list/charter.php
 SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
 as a free, non-commercial service to the software security community.
 Follow KRvW Associates on Twitter at: http://twitter.com/KRvW_Associates
 ___





___
Secure Coding mailing list (SC-L) SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php
SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.
Follow KRvW Associates on Twitter at: http://twitter.com/KRvW_Associates
___

Re: [SC-L] SearchSecurity: Badware versus malware

[Goertzel, Karen [USA]]

In other words, flaws and defects caused through developer error, ignorance, 
negligence etc. can be exploited to cause harm. So even if one could prevent 
actual intentional malicious inclusions in software, one hasn't eliminated the 
problem of exploitable flawed logic.

The megachallenge, of course, is looking for what one doesn't actually know is 
there. Which is why software security testing is so hard.

===
Karen Mercedes Goertzel, CISSP
Lead Associate
Booz Allen Hamilton
703.698.7454
goertzel_ka...@bah.com

I love deadlines. I like the whooshing sound they make as they fly by.
- Douglas Adams


From: sc-l-boun...@securecoding.org [sc-l-boun...@securecoding.org] on behalf 
of Peter G. Neumann [neum...@csl.sri.com]
Sent: 08 May 2012 11:30
To: Gary McGraw
Cc: Secure Code Mailing List
Subject: Re: [SC-L] SearchSecurity: Badware versus malware

The differences are marginal.
 What's worse, bad software or malicious software? ...

My book has a pervasive theme:
  Many things that could happen accidentally could be triggered
intentionally.
  Many things that happen intentionally could be triggered accidentally.

Trying to reduce one without the other may be foolhardy in most realistic
threat models.

___
Secure Coding mailing list (SC-L) SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php
SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.
Follow KRvW Associates on Twitter at: http://twitter.com/KRvW_Associates
___

___
Secure Coding mailing list (SC-L) SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php
SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.
Follow KRvW Associates on Twitter at: http://twitter.com/KRvW_Associates
___

Re: [SC-L] Fwd: [SEWORLD] SWEBOK Version 3 Call for Reviewers

[Goertzel, Karen [USA]]

Unfortunately, it seems like the SWEBOK folks still believe that if you have 
high-quality software, that will be sufficient to assure robustness against 
intentional threats. It also shows a touching lack of faith that there will 
never be an malicious participant in the SDLC intentionally sabotaging or 
subverting the code, test results, etc.

===
Karen Mercedes Goertzel, CISSP
Lead Associate
Booz Allen Hamilton
703.698.7454
goertzel_ka...@bah.com

I love deadlines. I like the whooshing sound they make as they fly by.
- Douglas Adams

From: sc-l-boun...@securecoding.org [sc-l-boun...@securecoding.org] on behalf 
of Martin Gilje Jaatun [secse-ch...@sislab.no]
Sent: 05 March 2012 07:02
To: Secure Coding
Subject: [SC-L] Fwd: [SEWORLD] SWEBOK Version 3 Call for Reviewers

Hi SC-L,

I would have hoped that Software Security should have been a topic area in 
SWEBOK, right alongside Software Quality, but it doesn't look like it...

-Martin

 Opprinnelig melding 
Emne:   [SEWORLD] SWEBOK Version 3 Call for Reviewers
Dato:   Fri, 2 Mar 2012 10:53:26 -0700
Fra:Dick Fairley dickfair...@gmail.commailto:dickfair...@gmail.com
Til:sewo...@sigsoft.orgmailto:sewo...@sigsoft.org



*Call for Reviewers of Three New Knowledge Area Descriptions for the*

*Guide to the Software Engineering Body of Knowledge*

The IEEE Computer Society is now soliciting public review comments on three
knowledge areas (KAs) for Version 3 of the Guide to the Software
Engineering Body of Knowledge (SWEBOK V3).  SWEBOK V3 is an update to the
2004 version of the SWEBOK Guide, which is also known as Technical Report
ISO/IEC TR 19759.  The 15 KAs in SWEBOK V3 are being published
incrementally as they become available for review.

The purposes of the SWEBOK Guide are: to characterize the contents of the
software engineering discipline; to promote a consistent view of software
engineering worldwide; to clarify the place of, and set the boundary of
software engineering with respect to other disciplines; to provide a
foundation for training materials and curriculum development; and to
provide a basis for certification and licensing of software engineers.

Three new KAs are now available for review (Software Engineering Methods
and Models; Software Maintenance; and Mathematical Foundations). These KAs
can be reviewed and comments can be submitted at:

computer.centraldesktop.com/swebokv3review/

The review period for these KAs extends from March 2 to March 31, 2012.

Three of the SWEBOK V3 KAs (Computing Foundations, Software Construction,
and Software Configuration Management) have been reviewed and the review
period is closed; the KA editors are resolving the public review
comments.  Resolution
of submitted comments for all KAs will be displayed on the SWEBOK V3 Web
site as they become available.  All review comments, as well the names and
countries of the reviewers providing the comments, will be made public.  Email
addresses, affiliations, and other identifying information of reviewers
will not be made public.

Present and potential reviewers will be notified when additional KAs become
available for review.  Each KA, when posted, will be available for review
for 30 calendar days from the date of posting.

 For further information or help please contact Dick Fairley, chair of the
SWEBOK V3 Change Control Board at 
d.fair...@computer.orgmailto:d.fair...@computer.org.


To contribute to SEWORLD, send your submission to
mailto:sewo...@sigsoft.org

http://www.sigsoft.org/seworld provides more
information on SEWORLD as well as a complete archive of
messages posted to the list.



___
Secure Coding mailing list (SC-L) SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php
SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.
Follow KRvW Associates on Twitter at: http://twitter.com/KRvW_Associates
___

Re: [SC-L] informIT: Building versus Breaking

[Goertzel, Karen [USA]]

What we need is to start building software that can fight back. Then we could 
become part of cyber warfare which is much sexier than software assurance. 
:)

===
Karen Mercedes Goertzel, CISSP
Booz Allen Hamilton
703.698.7454
goertzel_ka...@bah.com

Sorry, you have reached an imaginary number.
If you require a real number, please rotate
your phone by ninety degrees and try again.

From: sc-l-boun...@securecoding.org [sc-l-boun...@securecoding.org] on behalf 
of Rafal [ra...@ishackingyou.com]
Sent: 01 September 2011 22:59
To: co...@linus.mitre.org; shad...@gmail.com
Cc: a...@homeport.org; sc-l@securecoding.org
Subject: Re: [SC-L] informIT: Building versus Breaking

Steve,
  I think that the problem we have here is classic - defense isnta sexy. I 
think you could get DHS to sponsor one maybe? I think between some government 
funds, and some vendor support you'd be OK on costs, but the larger question of 
whether people would come... only time would tell.




Rafal Los - Security  Intelligence |  Voice/Text: (765) 247-2325  | Twitter: 
@RafalLos

Steven M. Christey co...@linus.mitre.org wrote:

While I'd like to see Black Hat add some more defensive-minded tracks, I
just realized that this desire might a symptom of a larger problem: there
aren't really any large-scale conferences dedicated to defense / software
assurance.  (The OWASP conferences are heavily web-focused; Dept. of
Homeland Security has its software assurance forum and working groups, but
those are relatively small.)

If somebody built it, would anybody come?

- Steve
___
Secure Coding mailing list (SC-L) SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php
SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.
Follow KRvW Associates on Twitter at: http://twitter.com/KRvW_Associates
___
___
Secure Coding mailing list (SC-L) SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php
SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.
Follow KRvW Associates on Twitter at: http://twitter.com/KRvW_Associates
___

Re: [SC-L] informIT: Building versus Breaking

[Goertzel, Karen [USA]]

There are these:

ISC(2) Secure Software Conference Series - 
https://www.isc2.org/PressReleaseDetails.aspx?id=650

ESSoS - http://distrinet.cs.kuleuven.be/events/essos/2012/

SecSE - http://www.sintef.org/secse

SSIRI - http://paris.utdallas.edu/ssiri11/


But your point is taken. Most of the conferences in this domain appear to be 
outside the U.S. I'm not sure what THAT says about U.S. attitudes about 
software assurance (though I have my suspicions). 

More important is the question of who actually attends these conferences. I'm 
in the process of updating some research on how and where software security 
assurance is being taught by colleges and universities, and what I'm finding is 
that the topic has been pretty much marginalised into an aspect of information 
assurance - i.e., it's being taught mostly to postgraduates who are majoring in 
IA and related disciplines - rather than an aspect of software development. 
There are exceptions, of course - but by and large that seems to be the trend. 
And I think the same is true of the conferences. It's the security wonks who 
care about software assurance much more than the actual software developers. 
Take a look at: http://zastita.com/index.php?det=64494

===
Karen Mercedes Goertzel, CISSP
Booz Allen Hamilton
703.698.7454
goertzel_ka...@bah.com

Sorry, you have reached an imaginary number.
If you require a real number, please rotate
your phone by ninety degrees and try again.

From: sc-l-boun...@securecoding.org [sc-l-boun...@securecoding.org] on behalf 
of Steven M. Christey [co...@linus.mitre.org]
Sent: 31 August 2011 16:45
To: Sergio 'shadown' Alvarez
Cc: Adam Shostack; Secure Code Mailing List
Subject: Re: [SC-L] informIT: Building versus Breaking

While I'd like to see Black Hat add some more defensive-minded tracks, I
just realized that this desire might a symptom of a larger problem: there
aren't really any large-scale conferences dedicated to defense / software
assurance.  (The OWASP conferences are heavily web-focused; Dept. of
Homeland Security has its software assurance forum and working groups, but
those are relatively small.)

If somebody built it, would anybody come?

- Steve
___
Secure Coding mailing list (SC-L) SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php
SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.
Follow KRvW Associates on Twitter at: http://twitter.com/KRvW_Associates
___

___
Secure Coding mailing list (SC-L) SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php
SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.
Follow KRvW Associates on Twitter at: http://twitter.com/KRvW_Associates
___

[SC-L] Special Issue of IJSSE: Software Safety Dependability - the Art of Engineering Trustworthy Software

[Goertzel, Karen [USA]]

For those who might be interested. There are still a couple weeks until the 
submission deadline


Karen Mercedes Goertzel, CISSP
Associate
Booz Allen Hamilton
703.698.7454
goertzel_ka...@bah.com

---

Special Issue of IJSSE
Theme:  Software Safety  Dependability - the Art of Engineering Trustworthy 
Software 


1.  Guest Editors

Guest Editor:
 Dr. Lei Wu
 School of Science and Computer Engineering 
 University of Houston-Clear Lake, Houston, Texas, U.S.A
 Email:  w...@uhcl.edu
Co-Guest Editor:
 Dr. Yi Feng
 Department of Computer Science and Mathematics, 
 Algoma University, Sault Ste. Marie, Ontario, Canada.
 Email:  yi.f...@algomau.ca 

2.  Important Dates
*   Submission of manuscripts: February 1, 2010
*   Notification of pre-acceptance/rejection: March 31, 2010
*   Submission of camera ready accepted papers: June 30 2010
*   Journal Special Issue Publication: January 2011

3.  Submission Guidelines

*   Submission guidelines through journal web site at:
http://www.igi-global.com/ijsse
*   Inquiries, manuscripts and any supplementary material should be
submitted to Guest Editor Dr. Lei Wu (w...@uhcl.edu), and Co-Guest
Editor, Dr. Yi Feng (yi.f...@algomau.ca) through E-mail 

4.  Call for Paper Content

Software Safety is an element of the total safety program. It optimizes
system safety  dependability in the design, development, use, and
maintenance of software systems and their integration with safety
critical application systems in an operational environment. Increasing
size and complexity of software systems makes it harder to ensure their
dependability. At the same time, the issues of safety become more
critical as we more and more rely on software systems in our daily life.
These trends make it necessary to support software engineers with a set
of techniques and tools for developing dependable, trustworthy software.
Software safety cannot be allowed to function independently of the total
effort. Both simple and highly integrated multiple systems are
experiencing an extraordinary growth in the use of software to monitor
and/or control safety-critical subsystems or functions. A software
specification error, design flaw, or the lack of generic safety-critical
requirements can contribute to or cause a system failure or erroneous
human decision. To achieve an acceptable level of dependability goals
for software used in critical applications, software safety engineering
must be given primary emphasis early in the requirements definition and
system conceptual design process. Safety-critical software must then
receive continuous management emphasis and engineering analysis
throughout the development and operational lifecycles of the system.
In this special issue, we are seeking insights in how we can confront
the challenges of software safety  dependability issues in developing
dependable, trustworthy software systems.  

5.  Topics of Interests
This special issue is designed for software professionals and decision
makers to explore the state-of-the-art techniques of Secure Software
Engineering practices targeted at software safety  dependability
challenges. Some suggested areas include, but not limited to: 

*   Safety consistent with mission requirements 
*   Secure software engineering with software security  trustworthy
  software  development
*   State-of-arts literature review of technology dealing with
  software system security
*   Identify and analysis of safety-critical functionality of
  complex systems  
*   Intrusion detection,  security management , applied cryptography
*   Derive hazards and design safeguards for mitigations 
*   Safety-Critical functions design and preliminary hazards
  analysis
*   Identification, evaluation, and elimination techniques for
  hazards associated with the system and its software, throughout the
  lifecycle  
*   Complexity of safety critical interfaces, software components 
*   Sound secure software engineering principles that apply to the
  design of the software-user interface to minimize the probability of
  human error
*   Failure  hazard models, including hardware, software, human and
  system are addressed in the design of the software 
*   Software testing  techniques targeting at software safety issues
  at different levels of testing 



--
Means should be taken to obviate one great objection -
at present felt with respect to sending private communi-
cations by telegraph - the violation of all secrecy.
- The Quarterly Review (UK), 1853
___
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 - 

Re: [SC-L] Where Does Secure Coding Belong In the Curriculum?

[Goertzel, Karen [USA]]

Not so much anti-social as untrusting, supicious, and paranoid. Actually, being 
highly social could provide an excellent cover to fool the bad guys into 
thinking one is a lot less security-savvy than one actually is.

Karen Mercedes Goertzel, CISSP
Associate
703.698.7454
goertzel_ka...@bah.com

From: sc-l-boun...@securecoding.org [sc-l-boun...@securecoding.org] On Behalf 
Of McGovern, James F (HTSC, IT) [james.mcgov...@thehartford.com]
Sent: Tuesday, August 25, 2009 2:09 PM
To: Secure Code Mailing List
Subject: [SC-L] Where Does Secure Coding Belong In the Curriculum?

There are several perspectives missing from the dialog:

- Before we even talk about secure coding, we need a course on secure
thinking. Most folks are indoctrinated into thinking positive which
blinds them from seeing vulnerabilities right in front of them. A prereq
on being antisocial might be a good start
___
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?

[Goertzel, Karen [USA]]

Your example is spurious as a refutation of what I was trying to say (as I 
suspect you already know). Obviously you're not going to try to teach a 
not-yet-verbal infant a self-preservation concept that requires even the most 
rudimentary reasoning.

That said, I'll be interested to hear from you in, say, a year and a half from 
now. And I still maintain that the intellectual maturity of a 
two-and-a-half-year-old hardly constitutes intermediate-to-advanced EXCEPT 
possibly when compared with that of a one-year-old.

Karen Mercedes Goertzel, CISSP
Associate
703.698.7454
goertzel_ka...@bah.com

From: Benjamin Tomhave [list-s...@secureconsulting.net]
Sent: Wednesday, August 26, 2009 12:27 AM
To: Goertzel, Karen [USA]
Cc: sc-l@securecoding.org
Subject: Re: [SC-L] Where Does Secure Coding Belong In the Curriculum?

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

[Goertzel, Karen [USA]]

I too remember learning proofs in Jr. High. And I also believe the main 
objective was to teach 12 and 13 year olds that it is possible to apply a 
repeatable, disciplined process to how they approach problem solving. Certainly 
not a worthless lesson, even if the mathematics involved are never used again.

Karen Mercedes Goertzel, CISSP
Associate
703.698.7454
goertzel_ka...@bah.com

From: sc-l-boun...@securecoding.org [sc-l-boun...@securecoding.org] On Behalf 
Of Brad Andrews [andr...@rbacomm.com]
Sent: Tuesday, August 25, 2009 4:23 PM
To: sc-l@securecoding.org
Subject: Re: [SC-L] Where Does Secure Coding Belong In the Curriculum?

I had proofs in junior high Geometry too, though I do not recall using
them outside that class.  I went all the way through differential
equations, matrix algebra and probability/statistics and I don't
recall much focus on proofs.  This was in the early 1980s in a good
school (Illinois), so it wasn't just modern teaching methods that were
too blame.  I am not sure that the proofs were all that useful for
understanding some things either, though the logic they taught has
value that I missed a bit of since I did hit some modern techniques.

--

Brad Andrews
RBA Communications
CISM, CSSLP, SANS/GIAC GSEC, GCFW, GCIH, GPCI


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

[Goertzel, Karen [USA]]

I see your point. On the other hand, there are times I worry that teach the 
hacker mentality approach to secure development training smacks a bit too much 
teaching future policemen the delights of robbery, rape, torture, and murder in 
order to prepare the to defend the public against robbers, rapists, torturers, 
and murders.

Definitely teach - with examples - what it is about software that makes it so 
easy to exploit and violate. But stop short of handing the students detailed 
blueprints and instructions, reinforced by lots of hands-on lab time. I'm just 
untrusting enough of human nature to worry that once some of them discover how 
much more fun it is to hack than to defend against hacking, what you'll end up 
with is not the next Bob Seacord but the next Kevin Mitnick.

At the very least, make psychological exams a prerequisite of acceptance into 
your class, so you can weed out the likely psychopaths and sociopaths.

Karen Mercedes Goertzel, CISSP
Associate
703.698.7454
goertzel_ka...@bah.com

From: sc-l-boun...@securecoding.org [sc-l-boun...@securecoding.org] On Behalf 
Of Olin Sibert [u3...@siliconkeep.com]
Sent: Tuesday, August 25, 2009 8:16 PM
To: sc-l@securecoding.org
Subject: Re: [SC-L] Where Does Secure Coding Belong In the Curriculum?

I'm mostly a lurker here, and I'm a practitioner rather than a
professional educator, but there's a viewpoint I haven't seem
much of that I want to support, namely:

  Exploits are FUN.

Teach from that angle, and I think you'll get more traction
___
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?

[Goertzel, Karen [USA]]

Your Picasso - or, perhaps, Frank Lloyd Wright would be a better analogy - 
definitely has a role in software development.  I want his creativity up front 
in the specification and high-level design of the building (the software 
system). But when it comes to detailed design and testing, I'm going to call in 
the engineers, and when it comes to coding, no-one does it better than skilled 
construction workers who have mastered the use of hammers, saws, adzes, etc. 

So yes - the coders are craftsmen. But the problem is that in software 
development, the roles are seldom so clearcut, especially not in Agile 
development. So one does find far too many craftsmen attempting the engineers' 
and architects' jobs without anything like the necessary training and 
certification of their competence to perform those functions.

Or maybe, if we accept the software development as an art analogy, our 
problem is we have way too many architects trying to code successfully.

Karen Mercedes Goertzel, CISSP
Associate
703.698.7454
goertzel_ka...@bah.com

From: sc-l-boun...@securecoding.org [sc-l-boun...@securecoding.org] On Behalf 
Of Jim Manico [...@manico.net]
Sent: Tuesday, August 25, 2009 11:17 PM
To: Benjamin Tomhave
Cc: sc-l@securecoding.org
Subject: Re: [SC-L] Where Does Secure Coding Belong In the Curriculum?

 I again come back to James McGovern's suggestion, which is treating
coding as an art rather than a science

Keep your Picasso out of my coding shop, world of discrete mathematics and 
predicate logic! I don't care how cheap his hourly is. :)

I'd prefer to think of coders as craftsman; we certainly are not artists, 
scientists or engineers. ;) And craftsman are bound by the laws of mathematics 
and the sponsors who pay us, artists have no bounds.

- Jim


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

[Goertzel, Karen [USA]]

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.

Great strategy! Our hacker friends will love it.

Karen Mercedes Goertzel, CISSP
Associate
703.698.7454
goertzel_ka...@bah.com

From: sc-l-boun...@securecoding.org [sc-l-boun...@securecoding.org] On Behalf 
Of Benjamin Tomhave [list-s...@secureconsulting.net]
Sent: Monday, August 24, 2009 8:35 PM
To: sc-l@securecoding.org
Subject: Re: [SC-L] Where Does Secure Coding Belong In the Curriculum?

Two quick comments in catching up on the thread...

First, security in the software development concept is at least an
intermediate concept, if not advanced
___
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?

[Goertzel, Karen [USA]]

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.

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?

...
___
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 is the size of this list?

[Goertzel, Karen [USA]]

Actually, we can't prove programs are bug free if by bug we also mean all 
possible anomalous behaviours. My colleagues keep pointing this out to me when 
I suggest that we should start leveraging the computational power of computing 
grids to analyze complex software the same way other researchers are using 
grids to develop models of the natural world, the human genome, etc. They keep 
quoting that bloke Kurt Gödel with his pesky little incompletness theorem as 
proof that 100% complete analysis of software cannot be done. Frankly, I'm 
beginning to think this is their excuse for not even trying to get me to the 
50%. But the point is, even if you can do everything right in terms of 
building software to be vulnerability-free and behaviourally-benign, you 
apparently cannot achieve 100% verification that you've done so. Ergo, 
assurance can never be 100%. 


Karen Mercedes Goertzel, CISSP
Associate
703.698.7454
goertzel_ka...@bah.com

From: sc-l-boun...@securecoding.org [sc-l-boun...@securecoding.org] On Behalf 
Of Brad Andrews [andr...@rbacomm.com]
Sent: Friday, August 21, 2009 11:41 AM
To: sc-l@securecoding.org
Subject: Re: [SC-L] What is the size of this list?

I completely agree with your final statement Karen, but I see a lot
more of the words aiming at the 100% mark and I think that is
ultimately a bad focus since it is unachievable and therefore will
waste focus and effort.

While on paper we can prove programs are bug free (security-related
or not), it doesn't work in practice.  I may be biased by my
experience, but you won't be able to design a perfect program anymore
than you can design a flawless piece of handmade furniture.  Flaws
happen.  They focus should be on minimizing them and reducing the risk
that any flaws that make it through will cripple the end product,
whether it be a wood table or a software program.

A recent CERT podcast implied that we could reach your 100% as we
matured and that has just stuck in my craw.  I don't think it really
is achievable, though making the case is going to take more than a
quick reply on this list.

--

Brad Andrews
RBA Communications
CISM, CSSLP, SANS/GIAC GSEC, GCFW, GCIH, GPCI

[snippety snip]
___
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?

[Goertzel, Karen [USA]]

Here's an extract from the Information Assurance Technology Analysis Center 
(part of DTIC) Software Security Assurance: A State of the Art Report 
(http://iac.dtic.mil/iatac/download/security.pdf):

Courses on secure software development, secure programming, etc., typically
begin by introducing common attacks against software-intensive information
systems and the vulnerabilities targeted by those attacks, then progress to
modeling, design, coding, and testing practices that software developers can 
adopt
to reduce the likelihood that exploitable vulnerabilities will appear in the 
software
they produce. The following is a representative sampling of such courses:

- Arizona State University: Software Security
- Ben-Gurion University (Beer-Sheva, Israel): Security of Software Systems
- Carnegie Mellon University (CMU) and University of Ontario (Canada):
Secure Software Systems
- George Mason University: Secure Software Design and Programming
- George Washington University: Security and Programming Languages
- Catholic University of Leuven (Belgium): Development of Secure Software
- New Mexico Tech: Secure Software Construction
- North Dakota State University: Engineering Secure Software
- Northeastern University: Engineering Secure Software Systems
- Northern Kentucky University, Rochester Institute of Technology, and
University of Denver: Secure Software Engineering
- Polytechnic University: Application Security
- Purdue University: Secure Programming
- Queen’s University (Kingston, ON, Canada): Software Reliability
and Security
- Santa Clara University: Secure Coding in C and C++
- University of California at Berkeley, Walden University (online): Secure
Software Development
- University of California at Santa Cruz: Software Security Testing
- University of Canterbury (New Zealand): Secure Software
- University of Nice Sophia-Antipolis (Nice, France): Formal Methods
and Secure Software
- University of Oxford (UK): Design for Security
- University of South Carolina: Building Secure Software.

As noted earlier, other schools offer lectures on secure coding and other
software security relevant topics within their larger software engineering or
computer security course offerings. At least two universities - the University
of Texas at San Antonio and University of Dublin (Ireland) - have established
reading groups focusing on software security.

As part of its Trustworthy Computing initiative, Microsoft Research
has established its Trustworthy Computing Curriculum program [309] for
promoting university development of software security curricula. Interested
institutions submit proposals to Microsoft, and those that are selected are
provided seed funding for course development.

Another recent trend is post-graduate degree programs with specialties
or concentrations in secure software engineering (or security engineering for
software-intensive systems). Some of these are standard degree programs,
while others are specifically designed for the continuing education of working
professionals. The following are typical examples:

- James Madison University: Master of Science in Computer Science with
a Concentration in Secure Software Engineering
- Northern Kentucky University: Graduate Certificate in Secure
Software Engineering
- Stanford University: Online Computer Security Certificate in Designing
Secure Software From the Ground Up
- University of Colorado at Colorado Springs: Graduate Certificate in
Secure Software Systems
- Walden University (online): Master of Science in Software Engineering
with a Specialization in Secure Computing
- University of Central England at Birmingham: Master of Science in
Software Development and Security
- Chalmers University (Gothenburg, Sweden): Master of Science in
Secure and Dependable Computer Systems.

In another interesting trend (to date, exclusively in non-US schools),
entire academic departments - and in one case a whole graduate school—are
being devoted to teaching and research in software dependability, including
security, e.g.:

- University of Oldenburg (Germany) TrustSoft Graduate School of
Trustworthy Software Systems
- Fraunhofer Institute for Experimental Software Engineering (IESE)
(Kaiserslautern, Germany): Department of Security and Safety
- Bond University (Queensland, Australia): Centre for Software Assurance.


Karen Mercedes Goertzel, CISSP
Associate
703.698.7454
goertzel_ka...@bah.com

From: sc-l-boun...@securecoding.org [sc-l-boun...@securecoding.org] On Behalf 
Of Gary McGraw [...@cigital.com]
Sent: Thursday, August 20, 2009 2:55 PM
To: Neil Matatall; Secure Code Mailing List
Subject: Re: [SC-L] Where Does Secure Coding Belong In the Curriculum?

hi neil,

For what it's worth, there is a list of universities with some kind of software 
security curriculum on page 98 of Software Security http://swsec.com.  
Remember, this list was created in 2006, and lots of other universities have 
jumped on the bandwagon since 

Re: [SC-L] embedded systems security analysis

[Goertzel, Karen [USA]]

A colleague and I have been looking at the problem a bit, in the context of 
need for survivability in safety-critical systems. Below is an extract of the 
paper Software Survivability: Where Safety and Security Converge authored by 
Larry Feldman, Ph.D., and myself, and presented by our colleague Theodore 
Winograd at the American Institute of Aeronautics and Astronautics' 
infot...@aerospace Conference in Seattle last spring.

There's also a brief discussion of security issues associated with embedded 
software in the DHS/DACS Enhancing the Development Life Cycle to Produce 
Secure Software - specifically pages 272-275. The document is freely 
downloadable after quick registration on the DACS (DTIC's Data and Analysis 
Center for Software) Web site: 
https://www.dacs.dtic.mil/techs/enhanced_life_cycles/

Karen Mercedes Goertzel, CISSP
Associate
703.698.7454
goertzel_ka...@bah.com

--

B.  Embedded No Longer Means Isolated

Before discounting a comparable threat to embedded systems, consider 
the following excerpt from Chapter seven of Exploiting Software [8] by Greg 
Hoglund and Gary McGraw: 

For no valid technical reasons, people seem to believe that embedded 
systems are invulnerable to remote software-based attacks. One common 
misconception runs that because a device does not include an interactive shell 
out of the box, then accessing or using ‘shell code’ is not possible. This is 
probably why some people (wrongly) explain that the worst thing that an 
attacker can do to most embedded systems is merely to crash the device. The 
problem with this line of reasoning is that injected code is, in fact, capable 
of executing any set of instructions, including an entire shell program that 
encompasses and packages up for convenient use standard, supporting [operating 
system]-level functions. It does not matter that such code does not ship with 
the device. Clearly, this kind of code can simply be placed into the target 
during an attack. Just for the record, an attack of this sort may not need to 
insert a complete interactive TCP/IP shell. Instead, the attack might simply 
wipe out a configuration file or alter a password. 
There are any numbers of complex programs that can be inserted via a 
remote attack on an embedded system. Shell code is only one of them. Even the 
most esoteric of equipment can be reverse engineered, debugged, and played 
with. It does not really matter what processor or addressing scheme is being 
used, because all an attacker needs to do is to craft operational code for the 
target hardware. Common embedded hardware is (for the most part) well 
documented, and such documents are widely available. 

One of the most widely publicized successful attacks on an embedded 
system was the 2002 hack of the flash memory of the Microsoft XBox game cube in 
order to access the algorithm used by the game cube’s cryptosystem to decrypt 
and verify its bootloader. [9] 
Now consider how safety-critical embedded systems—from temperature 
controls to medical devices to on-board airplane and automotive computers and 
sensors—are increasingly becoming network-accessible. For example, embedded 
software in implanted medical devices is now accessible via radio frequency 
identification (RFID) interfaces. [10] And telemedicine applications in use by 
DoD enable software-controlled surgical robots located in U.S. military 
facilities in Iraq to be operated via satellite uplinks by doctors at the U.S. 
Navy Hospital in Bethesda, Maryland. [11] 
Consider General Motors’ OnStar and its less familiar rivals (Ford’s 
RESCU and VEMS, Volvo’s OnCall, BMW’s Assist, Mercedes-Benz’s TeleAid and 
COMAND). These services all include the ability of call center representatives 
to perform remote telematic diagnostics of the onboard computers in their 
subscribers’ vehicles. The data they collect via transmissions from the cars’ 
computers are returned to the remote call centers via cellular or satellite 
phone links. 
Remote monitoring and diagnosis of automotive computers sounds benign 
enough (though there are significant privacy concerns associated with some of 
the data being gathered by these services), but OnStar has gone a step beyond 
simple observation to actual remote control of at least one of the automobile’s 
safety-critical onboard computers: the one that controls its ignition. As USA 
Today reported in October 2007, [12] the 1.7 million General Motors 2009 
vehicles equipped with OnStar now allow their owners to grant permission for 
OnStar to cooperate with the police if their vehicles are stolen; specifically, 
if a police car is involved in a high-speed car chase with a stolen 
OnStar-enabled vehicle, the police can request that the stolen vehicle’s engine 
“be remotely switched off through the OnStar mobile communications system”. The 
objective of this police/OnStar cooperation is laudable: it allows the police 
to terminate car chases 

Re: [SC-L] embedded systems security analysis

[Goertzel, Karen [USA]]

We looked at the problem of voting system security specifically in the context 
of insider threat for last year's IATAC State of the Art Report on the Insider 
Threat to Information Systems - some of which involved rogue developers 
engineering backdoors into such systems. Unfortunately the document is limited 
distribution and FOUO, so I can't excerpt here. But if you're interested and a 
government employee or contractor, let me know and I'll get you instructions on 
how to register with DTIC to obtain a copy.

Karen Mercedes Goertzel, CISSP
Associate
703.698.7454
goertzel_ka...@bah.com

From: sc-l-boun...@securecoding.org [sc-l-boun...@securecoding.org] On Behalf 
Of Jeremy Epstein [jeremy.j.epst...@gmail.com]
Sent: Thursday, August 20, 2009 5:39 PM
To: Arian J. Evans
Cc: Secure Coding List
Subject: Re: [SC-L] embedded systems security analysis

I spent a fair bit of time doing stuff relating to voting systems,
which all have embedded systems.  (I am not one of the experts who
pulls them apart, lest anyone think I'm claiming credit for them.)
They are supposedly closed systems, but every time someone competent
has tried to attack them, they've been successful - even if there are
no published APIs or documents, all of them have attack surfaces.  It...
___
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?

[Goertzel, Karen [USA]]

I think we need to start indoctrinating kids in the womb. Start selling Baby 
Schneier CDs alongside Baby Mozart. :)

Seriously, though, cyberspace is such an integral part of modern life, parents 
need to inculcate online security into their toddlers the same way they teach 
them to look both ways before crossing the street, and not to talk to or get 
into the car with strangers. In essence, we need to teach kids the virtual 
equivalents of these safe behaviours when they go online - which some of them 
are doing as early as age 4! If they can be brainwashed that early, they will 
come to have higher expectations of what SHOULD be present with regard to 
security properties in software-based systems. Then the notion won't seem alien 
to them. What will seem alien TO US is that they won't understand the struggles 
we've had to get people to start adding security. The idea of security having 
ever NOT been there will be bizarre to them.

Karen Mercedes Goertzel, CISSP
Associate
703.698.7454
goertzel_ka...@bah.com

From: sc-l-boun...@securecoding.org [sc-l-boun...@securecoding.org] On Behalf 
Of Mike Lyman [mlyman-ci...@comcast.net]
Sent: Friday, August 21, 2009 8:17 AM
To: Secure Coding
Subject: Re: [SC-L] Where Does Secure Coding Belong In the Curriculum?

Neil Matatall wrote:
 So where does secure coding belong in the curriculum?

 Higher Ed?  High School?

 Undergrad? Grad? Extension?

Secure coding needs to be taught anytime programming is taught
___
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?

[Goertzel, Karen [USA]]

I'm more devious. I think what needs to happen is that we need to redefine what 
we mean by functionally correct or quality code. If determination of 
functional correctness were extended from must operate as specified under 
expected conditions to must operate as specified under all conditions, 
functional correctness would necessarily require security, safety, fault 
tolerance, and all those other good things that make software dependable 
instead of just correct.


Karen Mercedes Goertzel, CISSP
Associate
703.698.7454
goertzel_ka...@bah.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.
___

Re: [SC-L] Certified Application Security Specialists

[Goertzel, Karen [USA]]

Yes, yes. We know. It's April 1st and all's right with the world.

--
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 SC-L Reader Dave Aronson
Sent: Wed 01-Apr-09 11:25
To: Secure Coding
Subject: [SC-L] Certified Application Security Specialists
 
Y'all-

I think I've finally found the right certification for me!  Check out
the Institute for
Certified Application Security Specialists, at http://www.asscert.com/ today!

-Dave

-- 
Dave Aronson: Have Pun, Will Babble | Work: davearonson.com | /\ ASCII
| Play: davearonson.net | \/ Ribbon
Specialization is for insects.| Life: dare2xl.com | /\ Campaign
-Robert A. Heinlein | Wife: nasjleti.net| EmailWeb
___
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] more relevant certifications

[Goertzel, Karen [USA]]

I would refer you to Section 7.2.2.2, Professional Certifications, starting on 
page 272 of Software Security Assurance: A State-of-the-Art Report which can 
be downloaded from: http://iac.dtic.mil/iatac/download/security.pdf

The report was published in July 2007; there may be additional certifications 
that have become available since then.

--
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 SC-L Reader Dave Aronson
Sent: Fri 20-Mar-09 09:59
To: Secure Coding
Subject: [SC-L] more relevant certifications
 
Paco Hope p...@cigital.com wrote:

 just as overly-simplistic as
 someone who disparages all credentials equally.

On that note... my company (BAE Systems) has been pushing for people
to become CISSPs, because in turn the main client (US gov) has been
pushing for contractors to have a bunch of CISSPs on the projects.
But, it seems as though that cert is very heavily loaded down with
things that front-line grunts like me will NEVER use.  I doubt I'll
ever get to decide where a data center is located, let alone the
entire building, nor what kind of fire detection/suppression or
physical security systems it has, and I can probably forget about
dictating HR policy as well.

So, I was considering other certs, that seem much more relevant.  The
main relevant one I've heard of is the GSSP (GIAC Secure Software
Programmer).

1) What do y'all think of that one?

2) It looked to me as though, other than perhaps from buying books,
there is one and only one GSSP practice exam, and it can be taken only
once.  Am I wrong?  Do you know of any others available for free,
preferably to be taken online?

3) Have you heard of any other certs relevant for those of us who
mainly design and implement computer-based systems, which will usually
undergo security scrutiny, and usually have little to no say about all
the other stuff around it?  (Preferably not technology-specific, as
opposed to for example a Secure Java or Secure Web-Apps cert.)
Compare and contrast, as the teachers would say

Thanks,
Dave

-- 
Dave Aronson: Have Pun, Will Babble | Work: davearonson.com | /\ ASCII
| Play: davearonson.net | \/ Ribbon
Specialization is for insects.| Life: dare2xl.com | /\ Campaign
-Robert A. Heinlein | Wife: nasjleti.net| EmailWeb
___
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] Secure Coding Books

[Goertzel, Karen [USA]]

Do you really mean secure coding only, or are you looking for books on 
secure software development more generally?

--
Karen Mercedes Goertzel, CISSP
Booz Allen Hamilton
703.902.6981
[EMAIL PROTECTED]




-Original Message-
From: [EMAIL PROTECTED] on behalf of Lawson, David L
Sent: Fri 07-Mar-08 08:45
To: sc-l@securecoding.org
Subject: [SC-L] Secure Coding Books
 
I've read several secure coding books in the past, and was wondering if
anyone has recommendations for secure coding books (preferably from the
last year or two).

Thanks,

David Lawson
___
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] Software process improvement produces secure software?

[Goertzel, Karen]

I've always had a question about this as well; specifically, what is really 
meant by adding security to a CMM?

I've always felt that the level at which the software (or system) process is 
defined by a CMM is too high and too abstract for the addition of security 
activities to be particularly meaningful.

My feeling is that a CMM is best used as a means of ensuring that the more 
detailed life cycle process is implemented in a disciplined manner, and that 
the amount of benefit, in terms of improvement of whatever property one is 
trying to improve - quality, reliability, security, safety - of the 
system/software that results from the process can be measured.

Where the actual security activities need to be defined and added are to the 
life cycle methodology. At best, adding security to a CMM can provide a very 
high level framework for helping someone who is shopping for a life cycle 
methodology know what to look for in that methodology. Is a CMM necessary for 
that purpose? I'm not convinced that it is.

I think what is likely to be more effective is a change in outlook by the 
practitioners who will be using the life cycle methodology. Their outlook needs 
to change so that a single question is asked before any choice or decision is 
made: What are the security implications of the choice/decision?

Of course, there's much more to it than just asking that question. And that's 
the reason we need to train developers, testers, etc. to (1) understand what 
security means, both at the software and system levels; (2) visualise and 
recognise the possible impact(s) each of their choices/decisions could have on 
the security of the system they are building (before the fact); (3) recognise 
the impacts each of their choices/decisions has had on the security of the 
system they have built (after the fact). Tools and techniques to help 
developers do the second and third of these are proliferating (e.g., threat 
modeling, attack trees, etc. for before-the-fact; analysis and testing tools 
for after-the-fact). But in the end, I believe the #1 factor that will 
contribute to the increased security of software is the developer's mentality. 
A security-aware...and more importantly, a security-*concerned...developer is 
more likely to (1) avoid making bad choices and decisions, and (2) to take an 
interest in, and pursue becoming, knowledgeable enough to correct bad choices 
that he/she did not avoid making earlier.

--
Karen Mercedes Goertzel, CISSP
Booz Allen Hamilton
703.902.6981
[EMAIL PROTECTED]




-Original Message-
From: [EMAIL PROTECTED] on behalf of Francisco Nunes
Sent: Tue 07-Aug-07 07:01
To: sc-l@securecoding.org
Subject: [SC-L] Software process improvement produces secure software?
 
Dear list members.

In june 2007, I had an interesting conversation with
Mr. Will Hayes from SEI during the Brazilian Symposium
on Software Quality. It was a great experience and I
am very grateful for this.

During our conversation, I made a question to Mr.
Hayes similar to this: Is it possible that only
software development process improvements can produce
secure software?

The scenario was only based on CMMI without security
interference.

His answer to this question was YES. My answer was
I DO NOT THINK SO.

His answer made me confuse and I had no arguments,
mainly, because my professional experience in software
process does not compare to Mr. Haye's experience.

Unfortunately, I also haven't found any statistics
which could answer this question. Please, if there is
one, let me know!

So, how about you, list members? What are your answers
to the question above?

I will try to organize your answers and present the
final result.

Thank you.

Yours faithfully,
Francisco José Barreto Nunes.


  Alertas do Yahoo! Mail em seu celular. Saiba mais em 
http://br.mobile.yahoo.com/mailalertas/
___
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] Anyone here attending the 6th Semi-Annual Software AssuranceForum

[Goertzel, Karen]

I'll be there, and presenting. I'd be interested in a BoF (but not a
BOF).

--
Karen Mercedes Goertzel, CISSP
Booz Allen Hamilton
703.902.6981
[EMAIL PROTECTED]  

 -Original Message-
 From: [EMAIL PROTECTED] 
 [mailto:[EMAIL PROTECTED] On Behalf Of Kenneth Van Wyk
 Sent: Thursday, February 22, 2007 4:03 PM
 To: Secure Coding
 Subject: [SC-L] Anyone here attending the 6th Semi-Annual 
 Software AssuranceForum
 
 Anyone else here attending the 6th Semi-Annual Software Assurance  
 Forum in Fairfax, Virginia on 8-9 March?  Any interest in an after- 
 event informal SC-L BoF and beer chat?  Let me know and I'll gladly  
 coordinate.
 
 (We already have several people signed up for the SC-L BoF 
 at S3 in  
 April.  If you sent me an email, I'll be sending you the details as  
 the event draws near.)
 
 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.
___

RE: [SC-L] Credentials for Application use

[Goertzel Karen]

I'm wondering whether role-based credentials, vs. individual user
credentials, might not make more sense here. Could the database owner
key be issued to a role vs. an individual identity? In this way, your
human users could be associated with a role that has a right to issue a
query to the database via the middleware, but only the middleware would
be associated with the role that had access to the key that could
decrypt the data that satisfies the user's query. This does not,
however, solve the problem of ensuring that the data remain secure once
they are decrypted. You don't mention the assurance level of the
encryption used in the database - i.e., does it exceed the strength of
SSL or TLS with encryption based on AES and Class 3 X.509 certificates?

Some interesting work doing on at INRIA in France that may be relevant:

   www-smis.inria.fr/Etheme_2._Data_confidentiality.html

Also, some combination of the capabilities provided by nCipher may be of
interest:

   www. ncipher.com

--
Karen Mercedes Goertzel, CISSP
Booz Allen Hamilton
703-902-6981
[EMAIL PROTECTED]

RE: [SC-L] Credentials for Application use

[Goertzel Karen]

Isn't a Single Sign-on System supposed to address exactly this kind of
problem? 

Users need to be authenticated individually. Also, they don't want to
have to deal with multiple sets of credentials and different login
procedures for different apps/systems.

Login requirements for various apps and backend systems vary.

The SSO system deals with the discrepancies.

Of course, and SSO is only as secure as (1) the assurance of the
credential on which it bases its authentication decisions (a static
password with an SSO is a really STUPID idea); (2) its own
trustworthiness and assurance. An SSO a piece of highly trusted software
in any environment - essentially the keys to the kingdom. Thus it
needs to be highly trustworthy and very strongly protected against
compromise. To my mind, that means (1) rigorous security testing before
acquisition and before deployment (not just relying on Common Criteria
EAL, because that doesn't indicate the real security of anything); (2) a
higher-assurance platform than Linux, UNIX, Windows, or OS X - at the
very least, a hardened, minimized operating system like those used to
host firewalls. Better yet, correctly-configured TSol.

--
Karen Goertzel, CISSP
Booz Allen Hamilton
703-902-6981
[EMAIL PROTECTED]  

 -Original Message-
 From: [EMAIL PROTECTED] 
 [mailto:[EMAIL PROTECTED] On Behalf Of Gizmo
 Sent: Wednesday, May 11, 2005 10:52 AM
 To: SC-L@securecoding.org
 Subject: RE: [SC-L] Credentials for Application use
 
 I have a similar situation in one of my applications.  The 
 customer wishes
 to secure the database.  Since we use a Btrieve database, the 
 only way to do
 this is be setting an owner name on the DB, and then 
 encrypting using the
 owner name as the password.  However, once the DB is secured, 
 you can't
 access it unless you have the owner name, and giving out the 
 owner name to
 everyone who uses the app to access the DB pretty much 
 defeats the whole
 purpose of the exercise.
 
 The only way I can see to deal with this is something 
 similar to what I've
 done in my app:
 
 The user provides the management console with the password to 
 secure the DB.
 The app encrypts the password using the blowfish algorithm 
 and a private
 key.  It then postpends a SHA1 hash, Base64 encodes the 
 result, and stores
 it in three places: a local configuration file, a remote 
 configuration file,
 and the registry.  All three stores are secured using an ACL 
 such that only
 the user the main server app runs under has access to the 
 data.  In the
 event that one of the stores is corrupted or tampered with 
 (as determined by
 the SHA1 hash) voting logic is used to determine which stored 
 password is to
 be discarded.
 
 I imagine that someone here has a better idea, and if so, I'd 
 love to hear
 it.
 
 Later,
 Chris
 
 -Original Message-
 From: [EMAIL PROTECTED] 
 [mailto:[EMAIL PROTECTED]
 Behalf Of Mikey
 Sent: Tuesday, May 10, 2005 6:49 PM
 To: SC-L@securecoding.org
 Subject: [SC-L] Credentials for Application use
 
 
 This is a broad question around the current practices and 
 recommendation of
 what not to do when it comes to credentials used by 
 applications to gain
 access to a resource or data stored elsewhere.
 
 As an example, I have some middleware components that need to 
 gain access
 to a data repository that contains sensitive information. The 
 middleware
 components and data repository reside in separate, distinct security
 boundaries protected by differing authentication and access control
 mechanisms.
 
 Application developers insists the only way to gain access to the data
 repository is to create a set of credentials for the 
 repository that only
 they can use. But because the middleware components are using 
 it, there is
 no requirement for a user to enter those credentials in order to
 authenticate usage. I guess I wouldn't want the users to know 
 the details
 of this set of credentials either.
 
 Short of creating a user credential for each user accessing 
 the application
 on the data repository side, they insist that they need to 
 store the userid
 and password in a static format somewhere on the middleware 
 server. For
 example, a configuration file or some part of the operating system.
 
 Is there a best practice guideline for this scenario? What have other
 people in the same situation been doing here?
 
 
 

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

[Goertzel Karen]

I think it's a matter of SHARED reponsibility. Yes, the programmers and
their managers are directly responsible. But it's consumers who create
demand, and consumers who, out of ignorance, continue to fail to make
the connection between bad software security and the viruses, privacy,
and other issues about which they are becoming increasingly concerned.

The consumer can't be held responsible for his ignorance...at least not
yet. Because practioners of safe software have not done a very good
job of getting the message out in terms that consumers, vs. other
software practioners and IT managers, can understand.

I propose that the following is the kind of message that might make a
consumer sit up and listen:

We understand that you buy software to get your work or online
recreation done as easily as possible. But being able to get that work
done WITHOUT leaving yourself wide open to exploitation and compromise
of YOUR computer and YOUR personal information is also important, isn't
it? 

A number of software products, including some of the most popular ones,
are full of bugs and other vulnerabilities that DO leave those programs
wide open to being exploited by hackers so they can get at YOUR personal
information, and take over YOUR computing resources. 

Why is such software allowed to be sold at all? Because no-one
regulates the SECURITY of the software products that these the companies
put out, least of all the programmers who write that software. And, more
importantly, because you the consumer hasn't been told before that you
can make a difference. You can vote with your feet. 

Demand that the software you use not be full of holes and 'undocumented
features' that can be exploited by hackers. When you go out to buy a
lawn mower, you wouldn't buy a model that has a well-published track
record of its blades flying off. By the same token, you shouldn't buy a
software package that has a well-documented track record of being
successfully compromised by viruses, Trojan horses, and other hacker
tricks.

If we can start to raise consumer awareness in terms that consumers can
understand (avoiding the arcane terminology of software practitioners),
maybe we can start reducing demand for notoriously insecure software
products, and increasing demand for software that is developed with
security in mind.

--
Karen Goertzel, CISSP
Booz Allen Hamilton
703-902-6981
[EMAIL PROTECTED]  

 -Original Message-
 From: [EMAIL PROTECTED] 
 [mailto:[EMAIL PROTECTED] On Behalf Of Michael Silk
 Sent: Wednesday, April 06, 2005 9:40 AM
 To: Kenneth R. van Wyk
 Cc: Secure Coding Mailing List
 Subject: Re: [SC-L] Application Insecurity --- Who is at Fault?
 
 Quoting from the article:
 ''You can't really blame the developers,''
 
 I couldn't disagree more with that ...
 
 It's completely the developers fault (and managers). 'Security' isn't
 something that should be thought of as an 'extra' or an 'added bonus'
 in an application. Typically it's just about programming _correctly_!
 
 The article says it's a 'communal' problem (i.e: consumers should
 _ask_ for secure software!). This isn't exactly true, and not really
 fair. Insecure software or secure software can exist without
 consumers. They don't matter. It's all about the programmers. The
 problem is they are allowed to get away with their crappy programming
 habits - and that is the fault of management, not consumers, for
 allowing 'security' to be thought of as something seperate from
 'programming'.
 
 Consumers can't be punished and blamed, they are just trying to get
 something done - word processing, emailing, whatever. They don't need
 to - nor should. really. - care about lower-level security in the
 applications they buy. The programmers should just get it right, and
 managers need to get a clue about what is acceptable 'programming' and
 what isn't.
 
 Just my opinion, anyway.
 
 -- Michael
 
 
 On Apr 6, 2005 5:15 AM, Kenneth R. van Wyk [EMAIL PROTECTED] wrote:
  Greetings++,
  
  Another interesting article this morning, this time from 
 eSecurityPlanet.
  (Full disclosure: I'm one of their columnists.)  The 
 article, by Melissa
  Bleasdale and available at
  http://www.esecurityplanet.com/trends/article.php/3495431, 
 is on the general
  state of application security in today's market.  Not a 
 whole lot of new
  material there for SC-L readers, but it's still nice to see 
 the software
  security message getting out to more and more people.
  
  Cheers,
  
  Ken van Wyk
  --
  KRvW Associates, LLC
  http://www.KRvW.com
 
 
 
 

RE: [SC-L] certification for engineers/developers?

[Goertzel Karen]

ISC(2), which sponsors the CISSP, co-developed with NSA a CISSP
Concentration called the ISSEP - Information Systems Security
Engineering Professional. The focus is really on the National Security
Agency's way of doing systems security engineering, as reflected in the
SSE-CMM methodology, and in the DITSCAP and DIACAP certification
processes. If you do work with the Intelligence Community, it may be
worth considering. For more info:

https://www.isc2.org/cgi-bin/content.cgi?category=3D523

In the commercial space, an organization called the EC-Council (EC for
e-commerce not European Community) is now offering two security
certifications specifically for software developers:  EC-Council
Certified Secure Programmer (ECSP) and Certified Secure Application
Developer (CSAD). I know nothing about the EC-Council, or how much value
or recognition these two certifications have or will get in future, but
it is interesting that someone has FINALLY come up with certifications
specifically addressing Software Assurance. For more info, check out:

http://www.eccouncil.org/ecsp/

--
Karen Mercedes Goertzel, CISSP
Booz Allen Hamilton
703-902-6981
[EMAIL PROTECTED]