Re: [SC-L] More on Cyber War
Ben, You're right, and that's the whole point of the conference. You should consider coming next year. I think you'd be particularly interested in the discussions on the Laws of Armed Conflict. In the meantime, conference content is being discussed on linkedin, with a wonderful summary of the Legal and Policy track presentations by Eneken Tikk, in the group Cyber Security Forum Initiative (Law and Policy Division). Also, the conference materials should eventually be made available on the website at http://www.ccdcoe.org/conference2010/ Julie On Jun 22, 2010, at 4:20 PM, Benjamin Tomhave wrote: > On 6/22/10 4:00 PM, Haroon Meer wrote: >> Hi.. >> > Howdy! > >> Would have considered it slightly off-list-topic, but the current >> thread seems to allow it in :> >> > It's Gary's fault! (we can blame him since he's on vacation:) > >> My slides from the 2010 Conference on Cyber Conflict are now online at >> [http://blog.thinkst.com/2010/06/conference-on-cyber-conflict-slides.html] >> > An interesting presentation, consistent with others I've seen on the > topic. The problem around the "cyberwar" (or "cyber conflict") stuff is > definitional. We need to be extremely careful using the word "war" as it > tends to have very specific connotations. You also get into issues about > defining what is or isn't "critical infrastructure" and the degree of > direct responsibility the government should own for responding to, or > coordinating response to, a major incident. Putting it in context for > this list, one extreme could say that everything considered "critical > infrastructure" could be subject from direct government oversight, > including requirements for appsec and secure coding, complete with > DoD/comparable testing, C&A, etc. fwiw. > > -ben > > -- > Benjamin Tomhave, MS, CISSP > tomh...@secureconsulting.net > Blog: http://www.secureconsulting.net/ > Twitter: http://twitter.com/falconsview > LI: http://www.linkedin.com/in/btomhave > > [ Random Quote: ] > "Confidence is contagious. So is lack of confidence." > Vince Lombardi > ___ > Secure Coding mailing list (SC-L) SC-L@securecoding.org > List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l > List charter available at - http://www.securecoding.org/list/charter.php > SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) > as a free, non-commercial service to the software security community. > 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] Looking for Experts
Are you an information security expert? We are currently conducting research into the characterization of information security failures, controls, and successes. In order to complete this research, we need to interview people who actually know something about the subject. The interview process takes approximately 45 minutes and is performed one-on-one (f2f) through structured questions. If you live/work in the DC metro area, we can come to you. If you are outside the DC metro area, we can conduct the interview over the phone. The results of this research will be documented in a master's degree thesis and in one or more journal articles. If you would be willing to lend your expertise to this research, please reply to me via email at [EMAIL PROTECTED] Thanks in advance! Julie J.C.H. Ryan, D.Sc. Assistant Professor Department of Engineering Management and System Engineering School of Engineering and Applied Science The George Washington University http://www.seas.gwu.edu/~jjchryan/
[SC-L] OT: Research in CIIP
Just FYI, the proceedings of the US-Japan Workshop on Critical information Infrastructure Protection (CIIP) is online: http://www2.gwu.edu/~usjpciip/ Julie J.C.H. Ryan, D.Sc. Assistant Professor Engineering Management and System Engineering George Washington University [Ed. Ok, not exactly software security, but I felt that some of you would find it interesting nonetheless. I found it noteworthy that a gathering on critical infrastructure protection wouldn't even mention software security. We have a long journey ahead of us... KRvW] An NSA certified Center of Academic Excellence in Information Assurance Education http://www.seas.gwu.edu/~jjchryan/ http://www.seas.gwu.edu/~infosec/
[SC-L] CFP: The 9th Colloquium for Information Systems Security Education
The 9th Colloquium for Information Systems Security Education http://www.ncisse.org/ 6-10 June, 2005 - Georgia Tech Campus, Atlanta, Georgia, USA This colloquium, the ninth in an ongoing annual series, will bring together leading figures from academia, government, and industry to address the national need for security and assurance of our information and communications infrastructure. The Colloquium for Information Systems Security Education (The Colloquium) is established to serve as a living body to bring government, industry, and academia together to meet those challenges. This goal requires both an information-literate work force that is aware of its vulnerability as well as a cadre of information professionals that are knowledgeable of the recognized "best practices" available in information security and information assurance. The colloquium solicits papers from practitioners, students, educators, and researchers. The papers should discuss course or lab development, INFOSEC curricula, standards, best practices, existing or emerging programs, trends, and future vision, as well as related issues. This includes the following general topics: • Assessment of need (e.g. how many information security workers/ researchers/ faculty are needed?) • Integrating information assurance topics in existing graduate or undergraduate curricula • Experiences with course or laboratory development • Alignment of curriculum with existing information assurance education standards • Emerging programs or centers in information assurance • Best practices • Vision for the future We particularly encourage papers that discuss tools, demonstrations, case studies, course modules, shareware, and worked examples that participants (and others) can use to help educate people in computer security. Papers reporting work in progress are also welcomed, especially if enough information to evaluate the work will be available at the time of the colloquium. Proceedings All papers will be published in a proceedings with ISBN. Submissions Please see the submission guideline site for detailed information on format and other requirements. Paper Selection Committee • Paper Track Chair: DR. Ronald Dodge, United States Military Academy, [EMAIL PROTECTED] • Paper Track Committee: TBA Registration The program committee will provide detailed registration information (including fees, suggested hotels, and travel directions) on 10 January 2005 at the conference web site, http://www.ncisse.org. Important Dates • Deadline for paper submission March 6, 2005 • Notification of acceptance or rejection April 1, 2005
Re: [SC-L] Bugs and flaws
8 principles with 2 more from physical security that "apply only
imperfectly to computer systems"
http://www.cap-lore.com/CapTheory/ProtInf/Basic.html
On Feb 7, 2006, at 9:59 AM, Jeff Williams wrote:
I'm not sure which of the three definitions in Brian's message you're
not
concurring with, but I think he was only listing them as strawmen
anyway.
In any case, there's no reason that static analysis tools shouldn't be
able
to find errors of omission. We use our tools to find these 'dogs that
didn't
bark' every day.
The tools can identify, for example, places where logging, input
validation,
and error handling should have been done. With a little work teaching
the
tool about your application, assets, and libraries, it's easy to find
places
where encryption, access control, and authentication should have been
done
but haven't.
In your hypothetical, if the API isn't ever invoked with an identity
and a
secret, there can't be authentication. If there's no call to an access
control component, we know at least that there's no centralized
mechanism.
In this case, the tool could check whether the code follows the
project's
standard access control pattern. If not, it's an error of omission.
If I remember correctly, Saltzer and Schroeder only suggested 8
principles.
Your hypo is closest to complete mediation, but touches on several
others.
But, in theory, there's no reason that static analysis can't help
verify all
of them in an application.
--Jeff
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
On Behalf Of Gary McGraw
Sent: Monday, February 06, 2006 11:13 PM
To: Brian Chess; sc-l@securecoding.org
Subject: RE: [SC-L] Bugs and flaws
Hi all,
I'm afraid I don't concur with this definition. Here's a (rather
vague)
flaw example that may help clarify what I mean. Think about an error
of
omission where an API is exposed with no A&A protection whatsoever.
This
API may have been designed not to have been exposed originally, but
somehow
became exposed only over time.
How do you find errors of omission with a static analysis tool?
This is only one of salzer and schroeder's principles in action. What
of
the other 9?
gem
P.s. Five points to whoever names the principle in question.
P.p.s. The book is out www.swsec.com
-Original Message-
From: Brian Chess [mailto:[EMAIL PROTECTED]
Sent: Sat Feb 04 00:56:16 2006
To: sc-l@securecoding.org
Subject:RE: [SC-L] Bugs and flaws
The best definition for "flaw" and "bug" I've heard so far is that a
flaw is
a successful implementation of your intent, while a bug is
unintentional. I
think I've also heard "a bug is small", a flaw is big", but that
definition
is awfully squishy.
If the difference between a bug and a flaw is indeed one of intent,
then I
don't think it's a useful distinction. Intent rarely brings with it
other
dependable characteristics.
I've also heard "bugs are things that a static analysis tool can
find", but
I don't think that really captures it either. For example, it's easy
for a
static analysis tool to point out that the following Java statement
implies
that the program is using weak cryptography:
SecretKey key = KeyGenerator.getInstance("DES").generateKey();
Brian
___
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
---
-
This electronic message transmission contains information that may be
confidential or privileged. The information contained herein is
intended
solely for the recipient and use by any other party is not authorized.
If
you are not the intended recipient (or otherwise authorized to receive
this
message by the intended recipient), any disclosure, copying,
distribution or
use of the contents of the information is prohibited. If you have
received
this electronic message transmission in error, please contact the
sender by
reply email and delete all copies of this message. Cigital, Inc.
accepts no
responsibility for any loss or damage resulting directly or indirectly
from
the use of this email or its contents.
Thank You.
---
-
___
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
___
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
Re: [SC-L] Secure Programming with Static Analysis
The US Dept of Defense has done some work on the procurement side of the problem. Here are two papers for those in very large bureaucracies who might be interested: Best Software Assurance Practices in Acquisition of Trusted Systems http://www.cisse.info/colloquia/cisse10/proceedings10/pdfs/papers/ S02P03.pdf Software Assurance: Five Essential Considerations for Acquisition Officials http://www.stsc.hill.af.mil/CrossTalk/2007/05/0705PolydysWisseman.html On Jul 9, 2007, at 1:16 PM, McGovern, James F (HTSC, IT) wrote: > If you are seeking additional book ideas for this series, may I > suggest > posting to [EMAIL PROTECTED] > > There are two books that I would love to see: > > - Designing Secure Software - Not everything is about the code > - Procuring Secure Software - Most enterprises nowadays buy > software vs > build it > > > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Gary McGraw > Sent: Thursday, July 05, 2007 9:01 AM > To: 'Brian Chess'; 'sc-l@securecoding.org' > Subject: Re: [SC-L] Secure Programming with Static Analysis > > Hi sc-l, > > I have read this awesome book (more than once) and can vouch for > it. It > is an important part of the addison-wesley software security > series, the > series that includes: > Software Security www.swsec.com > Rootkits > Exploiting Software > Building Secure Software > (and any day now Exploiting Online Games) > > For more on the series, see www.buildingsecurityin.com. We are always > on the lookout for more titles for the series, especially if they dive > deeply into one of the seven touchpoints, so if you have a book idea > please let me know. > > Meanwhile, click on this link and buy Brian and Jacob's book: > http://www.amazon.com/dp/0321424778 > > gem > > company www.cigital.com > podcast www.cigital.com/silverbullet > blog www.cigital.com/justiceleague > book www.swsec.com > > > > ** > *** > This communication, including attachments, is > for the exclusive use of addressee and may contain proprietary, > confidential and/or privileged information. If you are not the > intended > recipient, any use, copying, disclosure, dissemination or > distribution is > strictly prohibited. If you are not the intended recipient, please > notify > the sender immediately by return e-mail, delete this communication and > destroy all copies. > ** > *** > > > ___ > Secure Coding mailing list (SC-L) SC-L@securecoding.org > List information, subscriptions, etc - http://krvw.com/mailman/ > listinfo/sc-l > List charter available at - http://www.securecoding.org/list/ > charter.php > SC-L is hosted and moderated by KRvW Associates, LLC (http:// > www.KRvW.com) > as a free, non-commercial service to the software security community. > ___ ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. ___
Re: [SC-L] Software process improvement produces secure software?
A simple way to understand why implementing software development process improvement will not necessarily produce secure software is to read the Common Criteria. yes, I know that it's opaque and hard to understand, but once you have gone through the process of writing a Protection Profile for an implementation independent information technology application, it becomes a lot clearer why simply having a good software development process does not imply secure software. which is why I make all my students write a protection profile on a topic that I pick (the latest ones centered around computer forensics tools) On Aug 7, 2007, at 7:01 AM, Francisco Nunes wrote: > Dear list members. > > In june 2007, I had an interesting conversation with > Mr. Will Hayes from SEI during the Brazilian Symposium > on Software Quality. It was a great experience and I > am very grateful for this. > > During our conversation, I made a question to Mr. > Hayes similar to this: "Is it possible that only > software development process improvements can produce > secure software?" > > The scenario was only based on CMMI without security > interference. > > His answer to this question was "YES". My answer was > "I DO NOT THINK SO". > > His answer made me confuse and I had no arguments, > mainly, because my professional experience in software > process does not compare to Mr. Haye's experience. > > Unfortunately, I also haven't found any statistics > which could answer this question. Please, if there is > one, let me know! > > So, how about you, list members? What are your answers > to the question above? > > I will try to organize your answers and present the > final result. > > Thank you. > > Yours faithfully, > Francisco José Barreto Nunes. > > > Alertas do Yahoo! Mail em seu celular. Saiba mais em > http://br.mobile.yahoo.com/mailalertas/ > ___ > Secure Coding mailing list (SC-L) SC-L@securecoding.org > List information, subscriptions, etc - > http://krvw.com/mailman/listinfo/sc-l > List charter available at - > http://www.securecoding.org/list/charter.php > SC-L is hosted and moderated by KRvW Associates, LLC > (http://www.KRvW.com) > as a free, non-commercial service to the software security community. > ___ > Julie J.C.H. Ryan, D.Sc. Assistant Professor Engineering Management and System Engineering George Washington University An NSA certified Center of Academic Excellence in Information Assurance Education http://www.seas.gwu.edu/~jjchryan/ http://www.seas.gwu.edu/~infosec/ ___ 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. ___
