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]" 
 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]]

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

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 enoug

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

[Goertzel, Karen [USA]]

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. I'm delighted to 
see someone with your influence start warning those who confuse software 
correctness and safety with software security of the potential havoc that can 
potentially be wrought by malevolent actors as these little widgets become 
increasingly networked and even Internet-accessible.

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. Certain physical systems and devices really should NEVER be connected 
to the public Internet - e.g., most Industrial Control Systems, all medical 
devices, any plane, train, or automobile. And others really never NEED to be 
Internet-connected. I mean, do we really, REALLY need to be able to access our 
refrigerators or washing machines over the Web? Aren't we all growing obese 
enough without making things so bloody convenient that we needn't even walk the 
20 feet from the bedroom to the kitchen or laundry room to program the coffee 
maker or start another rinse cycle?

Manufacturers of the latter need to stop trying so bloody hard to "improve" 
products that no longer need improvement. There does come a time when a 
technology goes as far as it can go - and any further attempts to "improve" it 
are either purely cosmetic, unnecessary, or dangerous. I wish all these 
manufacturers who waste their times trying to invent a better toaster would, 
instead, invent something entirely new to solve a problem that hasn't already 
been solved quite adequately for many decades. No wonder American manufacturing 
is no longer competitive. All they do is continually rearrange deck chairs on 
the Titanic to improve the view as the boat sinks, instead of inventing a new 
means of transportation that actually CANNOT be taken down by an iceberg.


===
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: SC-L [sc-l-boun...@securecoding.org] on behalf of security curmudgeon 
[jeri...@attrition.org]
Sent: 06 July 2014 01:21
To: Gary McGraw
Cc: Chandu Ketkar; Secure Code Mailing List
Subject: [External]  Re: [SC-L] SearchSecurity: Medical Devices and Software 
Security

On Mon, 30 Jun 2014, Gary McGraw wrote:

: Chandu Ketkar and I wrote an article about medical device security based
: on a talk Chandu gave at Kevin Fu?s Archimedes conference in Ann Arbor.
: In the article, we discuss six categories of security defects that
: Cigital discovers again and again when analyzing medical devices for our
: customers.  Have a look and pass it on:
:
: http://bit.ly/1pPH56p
:
: As always, your feedback is welcome.

Per your request, my feedback:

Why do so many security professionals think we need yet another article on
medical devices that give a high-level overview, that ultimately boils
down to "medical devices are not secure"?

We see these every month or three, and have for a long time. Other than
medical vendors who are very resistent to the idea that their devices have
issues, who is this written for? Who exactly outside medical vendors think
that those devices are secure?

These articles do nothing.. absolutely nothing, to fix problems. They are
bandwagon articles jumping on the 'medical security' wave that has some
attention right now. Everyone writing these articles seems to be
completely new to the medical arena. Most that write this crap that I have
talked to can't speak to any of the history of medical disclosures. Names
like Fu and Halperin are foreign to them, and the importance of 1985 in
the timeline of medical issues is lost on them. If you find yourself
Googling any of those, thanks for proving my point.

This shit is not new. These articles are NOT advancing our field or the
medical field. Sure, you are getting a slice of attention for the issue,
but mostly in our echo chamber.

Finally, your intro. "Since 1996 my company has analyzed hundreds of
systems..." Really? Hundreds? You might want to fix that, else you come
across as complete n00bz in the industry. I've done single engagements
that involved tends of thousands of machines. Perhaps you want to qualify
that to mean hundreds of vendors? Hundreds per months/year?

To illustrate I am not the only one who feels this way:
https://twitter.com/attritionorg/status/485652525589086209

1 minute later:
https://twitter.com/SteveSyfuhs/status/485652988044656640

Seriously, dare to evolve.

.b
___
Secure Coding mailing

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] 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] 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  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" 
> To: "Bobby G. Miller" 
> Cc: "Secure Coding List" 
> 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  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 - http://www.securecoding.org/list/charte

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]" :

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

Oops. I meant to say "touching faith" not "touching lack of faith".

===
Karen Mercedes Goertzel, CISSP

____

From: "Goertzel, Karen [USA]" 
mailto:goertzel_ka...@bah.com>>
Date: Wed, 7 Mar 2012 09:53:18 -0500
To: Martin Gilje Jaatun mailto:secse-ch...@sislab.no>>, 
Secure Code Mailing List mailto:SC-L@securecoding.org>>
Subject: Re: [SC-L] Fwd: [SEWORLD] SWEBOK Version 3 Call for Reviewers

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<mailto: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<mailto:sc-l-boun...@securecoding.org> 
[sc-l-boun...@securecoding.org<mailto:sc-l-boun...@securecoding.org>] on behalf 
of Martin Gilje Jaatun [secse-ch...@sislab.no<mailto: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 <mailto:dickfair...@gmail.com>
Til:sewo...@sigsoft.org<mailto: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 
threeknowledge 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 
becomeavailable 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.org<mailto:d.fair...@computer.org>.


To contribute to SEWORLD, send your submission to
mailto:seworld@sigsoft.orghttp://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] 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 
Til: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.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"  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 - http://www.securecoding.o

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

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

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

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

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

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] 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] 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] 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] Customer Demand

[Goertzel, Karen [USA]]

I think we need a multifaceted approach that includes supply side, demand side, 
insurance companies, consumer protection organisations, etc. etc. 

We need regulation with legal penalties - as exist for airlines, for example - 
for software firms that fail to meet minimal standards for quality - which must 
be defined to include security (using demonstrated linkages to existing 
legislation as a catalyst - i.e., non-secure software makes it impossible to be 
HIPPA, FISMA, SOX, PCI, etc. compliant).

We need a system of evaluation (like Good Housekeeping seal of approval, but 
NOT like Common Criteria) for consumers to be able to easily determine which 
software meets the minimum standards for "goodness".

We need the insurance firms that are now offering security and CIP related 
products to add software security criteria to their definitions, so that their 
customers who buy demonstrably secure software get breaks on their premiums, 
and those that willfully engage in risky behaviours - i.e., persisting in use 
of bad software - are penalised by higher premiums or, ultimately, having their 
coverage dropped.

We need to educate end users as we did with seatbelts and cigarettes - a series 
of really good public service advertisements that clearly and engagingly depict 
what happens as a result of AVOIDABLE (by developers) security-related failings 
in software. With outlets like YouTube, the budget to broadcast such 
advertisements would be significantly smaller than it would have been when only 
the media outlets were big commercial networks.

Just some ideas - no doubt some better than others. The real message is "Yes, 
we need to change consumer behaviour" - but that alone won't get us where we 
need to go. 

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 12:08 PM
To: sc-l@securecoding.org
Subject: [SC-L] Customer Demand

While no customer is likely to say they don't care about software
working now that we are past Y2K, they don't think about it at all and
are unlikely to allow any schedule slippage to allow for making sure
that is true.

Customers only really care about the things they will pay for.  Many
companies claim they "can't stand" poor software or services, but they
still pay for them, so they will keep getting them.

Until we convince them that good security really is important and that
they must demand and pay for it, we won't make the progress we want to
make.

How many companies wouldn't even be doing the PCI level of effort if
they weren't forced to do so?  How many strictly limit it to their
"PCI environment" rather than looking at the risk to the whole
enterprise?  Even major breaches don't help since the "it can't happen
here" attitude is common all over, in spite of the fact it is a risky
stance.

While part of this is just a cynical rant, I think the base point is
that we have a whole lot more selling to do on the need for software
security before we can properly place it throughout the curriculum.
That sales job is hard.  The fact a few people have "gotten it"
doesn't mean most have or that we are completely ready for the next
step.

I realize many here may not be saying that, but that is the message I
get stepping back.  And I am a dreamer/visionary.  I like to think
well ahead of things, but focusing too much there makes us likely to
continue to be a niche area, leaving lots of vulnerabilities.

Wouldn't a better focus be on the customer demand end?  Stirring that
up will do more to advance secure development than any number of
maturity models.  Unfortunately, it is a much more difficult task.  I
would bet it is also not as conceptually interesting to many.

--

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


Quoting Martin Gilje Jaatun :

> His stance on this
> is that "if security were important to the customer, the customer would
> provide and prioritize security requirements". To me, this is a bit like
> saying "If the customer doesn't explicitly state that the software
> should be Y2k-proof, he/she is not really bothered about 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.
___

___
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 

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] 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] What is the size of this list?

[Goertzel, Karen [USA]]

Interesting. My definition of "secure" is for software is "dependable, 
trustworthy, and survivable (or, if you prefer, resilient)", i.e., 

(1) It's got to behave correctly and predictably; 

(2) It's got to behave non-maliciously and also not be subvertible (i.e., no 
weaknesses that can be exploited as vulnerabilities); 

(3) When it comes under attack, 1 & 2 need to hold true for as long as possible 
before the software's execution gracefully degrades and ultimately fails; when 
it does fail, it must do so in a manner that doesn't make it, its data, or its 
resources vulnerable to further compromise, and it must recover to an 
acceptable level of operation (which, obviously, needs to be specified) as 
quickly as possible, with as little damage as possible (and having minimised 
the extent of that damage).

Obviously, there's very little software that can satisfy all three of these 
criteria 100%. But even 50% is better than 0%.

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

From: Peter G. Neumann [neum...@csl.sri.com]
Sent: Thursday, August 20, 2009 6:50 PM
To: Matt Bishop
Cc: Goertzel, Karen [USA]; Secure Coding List
Subject: Re: [SC-L] What is the size of this list?

Let me amplify what Matt Bishop has said.
I tend to deal with TRUSTWORTHINESS, which encompasses
security, reliability, survivability, human safety, and anything
else that you have to trust whether you like it or not.
Security is only one aspect of it.  Long ago Butler Lampson
wrote a paper pointing out that if it is not secure, it won't
be reliable, and if it is not reliable, it is may not be secure.
That was applied to access controls in hardware, but it is equally
applied to SYSTEMS.  Also, all of those trustworthiness properties
tend to be emergent properties of the entire system/enterprise/whatever.
Beware of folks who tell you their crypto algorithm (for example) is
100% secure, and ignore that fact that if it badly implemented or the
keys are stored in an unsecure operating system, then all bets are off
and 100% secure becomes 0% secure.

end of soapbox, which some of you have heard from me before.

Peter

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

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" .  
Remember, this list was created in 2006, and lots of other universities have 
jumped on the bandwagon since

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] What is the size of this list?

[Goertzel, Karen [USA]]

As far as I'm concerned, being able to understand English is crucial to 
meaningful interpretation of literature written in that language, and being 
able to write and speak English with mastery is crucial to effective 
self-expression as a critic. So English mastery is not just "incidental and 
important", it is absolutely vital to the success of the English major who 
aspires to more than mediocrity.

I feel the same way about software development. Writing software sloppily 
results in software the functional objectives of which can be subverted, either 
accidentally or intentionally. Such software cannot be said to satisfy those 
objectives, and thus it must be seen as failing, at least partially. It's only 
because we have accepted such partial failure for as long as there has been 
software that our standards for what we consider "goodness" for software are so 
poor. If we applied the same poor standards to safety-critical mechanical 
systems a heck of a lot more of us would be reading this mailing list from 
hospital beds, nursing home rooms, or the afterlife. That's if they even have 
Internet access in the afterlife.

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 Matt Bishop [bis...@cs.ucdavis.edu]
Sent: Thursday, August 20, 2009 9:27 AM
To: Secure Coding List
Subject: Re: [SC-L] What is the size of this list?

...So I agree with what Rob posted, and I did have one thought. Is
writing good English a "minor" objective of an English major?
Probably, in the sense English curricula focus on interpretation of
literature, literary criticism, and other aspects of literature. But
it's an essential one. So perhaps "incidental and important" describes
how I feel better than "minor".

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

[SC-L] Mocana's NanoDefender

[Goertzel, Karen [USA]]

I came across this while doing some research into antimalware tools. If it 
actually work,s it seems like a nifty little trick to have in one's "secure 
coding" back pocket.

http://mocana.com/NanoDefender.html

--
Karen Mercedes Goertzel, CISSP
Booz Allen Hamilton
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] Insecure Java Code Snippets

[Goertzel, Karen [USA]]

The NIST SAMATE Reference Dataset has mainly C code in it, but there is also 
Java, C++, and PHP. There's a search function that allows you to search by 
programming language to find what you want.

http://samate.nist.gov/SRD/

--
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 Brad Andrews
Sent: Wed 06-May-09 13:41
To: sc-l@securecoding.org
Subject: [SC-L] Insecure Java Code Snippets
 


Does anyone know of a source of insecure Java snippets?  I would like  
to get some for a monthly meeting of leading technical people.  My  
idea was to have a "find the bug" like the old C-Lint ads.

Does anyone know of a source of something like this.

Brad
___
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] 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| Email<>Web
___
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  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| Email<>Web
___
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] BSIMM: Confessions of a Software Security Alchemist(informIT)

[Goertzel, Karen [USA]]

Except when they're hardware bugs. :)

I think the differentiation is also meaningful in this regard: I can specify 
software that does non-secure things. I can implement that software 100% 
correctly. Ipso facto - no software bugs. But the fact remains that the 
software doesn't validate input because I didn't specify it to validate input, 
or it doesn't encrypt passwords because I didn't specify it to do so. I built 
to spec; it just happened to be a stupid spec. So the spec is flawed - but the 
implemented software conforms to that stupid spec 100%, so by definition it not 
flawed. It is, however, non-secure.

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




-Original Message-
From: sc-l-boun...@securecoding.org on behalf of Benjamin Tomhave
Sent: Thu 19-Mar-09 19:28
To: Secure Code Mailing List
Subject: Re: [SC-L] BSIMM: Confessions of a Software Security 
Alchemist(informIT)
 
Why are we differentiating between "software" and "security" bugs? It
seems to me that all bugs are software bugs, ...
___
Secure Coding mailing list (SC-L) SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php
SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.
___

Re: [SC-L] Announcing LAMN: Legion Against MeaninglesscertificatioNs

[Goertzel, Karen [USA]]

The one I've decided to forego is the new ISC(2) CSSLP. Anyone who believes 
alphabet soup says more about one's qualifications than one's resume and list 
of publications is not someone I particularly want to spend time convincing of 
my competence regardless.

I am highly sceptical of those who take special training, study, or do anything 
extraordinary other than "on the job" to prepare for professional certification 
exams. To me these exams should demonstrate one's actual competence and 
knowledge gained doing work in the field being tested; they should not  merely 
demonstrate one's abilities to cram for an exam.

The reason I have the CISSP is that my job requires it. Besides, for me the 
level of effort to pass the exam was negligible. Had it not been - i.e., had 
nearly 10 years specifying and architecting cross domain solutions and high 
assurance operating systems, and doing risk analyses and COOPs NOT prepared me 
to pass the exam in just over two hours without any additional study - I really 
would have felt I had no business calling myself a professional in the field.


--
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: Thu 19-Mar-09 10:14
To: Secure Coding
Subject: Re: [SC-L] Announcing LAMN: Legion Against MeaninglesscertificatioNs
 
Jeremy Epstein  wrote:

> I'm pleased to announce the creation of LAMN, the Legion Against Meaningless
> certificatioNs.  If you don't have a CISSP, CISM, MCSE, or EIEIO - and
> you're proud of it - this group is for you.

Heh.  I'm going to be giving a speech today in which I mention "PMPs,
CISSPs, MCSEs, MDs, JDs, DDSes, and other assorted CAS -- that's
Certified Alphabet Soup".

-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| Email<>Web
___
Secure Coding mailing list (SC-L) SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php
SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.
___


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

[SC-L] Enhancing the Development Life Cycle to Produce Secure Software

[Goertzel, Karen [USA]]

The Department of Homeland Security Software Assurance Program's "Enhancing the 
Development Life Cycle to Produce Secure Software" (which supercedes their 
previous guidance document on secure software development, "Security in the 
Software Life Cycle") can be downloaded - after free online registration - from 
the DoD Data and Analysis Center for Software's website at:

https://www.thedacs.com/techs/enhanced_life_cycles/

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


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

[SC-L] Interesting academic job announcement

[Goertzel, Karen [USA]]

I stumbled across this and thought it was worth sharing in case there's anyone 
out there looking for an academic position in Europe:


 Two PhD Positions
  in
   Secure Software and Languages

   Department of Computer Science
   Katholieke Universiteit Leuven, Belgium

Applications are invited for two PhD positions within the DistriNet 
Research Group at the Katholieke Universiteit Leuven, Belgium.
The research will be conducted under the supervision of David Clarke.

* Research topics:

These positions are devoted to research on secure software and languages, 
including, but not limited to:
* modelling highly adaptable trustworthy systems
* types and models for software families
* logic and type systems for security; ownership types; pluggable types
* programming languages for secure software

* Profile & skills

- Clear interest in and knowledge of the subject, based on education, work 
or research experience
- Masters in Computer Science or Informatics 
- Team player; capability to work in an international research team
- Proficiency in English and excellent communication skills, both oral 
and written 
- Prior knowledge in the areas of type systems, security, programming
languages and/or formal methods is an advantage.

* About DistriNet

The "Distributed systems and computer Networksâ" (DistriNet) research 
group was founded in 1984 as part of the Department of Computer Science 
at the K.U.Leuven. DistriNet's research focus and scope is twofold: 
distributed softwareâ and secure software. 
The group works on a wide range of topics including computer networks, 
middleware, internet architectures, network and software security, 
embedded systems and multi-agent systems. DistriNet's research is generally
application driven and often conducted in collaboration with industry 
partners.

Currently DistriNet counts 60 members (8 professors, 12 post-docs and 
45 junior researchers) and participates in about 30 national and 
international research projects. The annual budget amounts to approximately
5MEuro. More information on projects and publications can be found on the 
DistriNet web pages: 

http://distrinet.cs.kuleuven.be/ 

* About Leuven

Lively Leuven is a  picturesque and upbeat Flemish city, just 25km from 
Brussels, and within 3 hours of major European centres such as Antwerp, 
Amsterdam, London and Paris. Leuven is shaped by its healthy student 
population - some 25,000 of them - more than a quarter of the town's 
population.

* Further Information and Application Procedure

Requests for further information and other informal enquiries can be sent
to:
Dr. David Clarke
David.Clarke at cs.kuleuven.be

Those interested in the position are asked to send e-mail to the address
given above. Full Details of the application process are available upon
request, but an application will include:

1. A cover letter stating the applicant's interest in the project.

2. A full curriculum vitae, including an abstract of the applicant's
   master's thesis and the name of their supervisor.

3. Letters of recommendation or references from at least two
   scientific staff members. (Letters of recommendation should either
   be included along with the application, or should arrive
   separately promptly.)

4. A completed application for postgraduate study at the K.U.Leuven.

Applications and instructions are available at

http://www.kuleuven.be/phd/

Applications will be considered until the position is filled, but those
received on or before 15 August 2008 will have priority.

The PhD positions are for 4 years. 
The start date is negotiable, 1 October 2008 at the earliest.

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