Re: [SC-L] Where Does Secure Coding Belong In the Curriculum?
The "just get the bloody thing to work" is usually an attitude foisted
on developers by the business side.
I work in an internal application security function for a large
enterprise and i'm yet to meet a developer who wasn't concerned about
security.
Developer education is very important and we have a lot of it
available for out developers, some of it even compulsory.
However, unless there is the will of the business behind it, developer
concerns are oft pushed aside in the interest of expediency.
I find the business side usually does have a genuine interest in
"security" and "quality", however they are concepts that remain
largely unquantifiable, and in the case of security you only need to
mess up once to end up with a nasty situation.
It's can be a tough sell getting time to focus on these things, given
they can be so vague. In the case of my organisation, business side
support comes from both internal advocacy of security practises by our
function and externally imposed legal requirements. Mostly the latter
;)
Filtering inputs is NOT hard, and most developers are getting better
at things like that. However, the problems of application security go
beyond the developer level, and it's important not to lose sight of
that fact. If there were an easy solution everything would already be
perfectly secure.
Pete
On Wed, Aug 26, 2009 at 12: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.
>
> 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.
> ___
>
___
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 Assist to Find Least Privilege
I've always thought systrace was nifty http://www.citi.umich.edu/u/provos/systrace/ It's on a different level than .net/java, but I don't see why something like that couldn't be built in to the CLR. As to developers vs management, unless there is high level support for security, developers are always going to struggle justifying time spent on these things. They are usually under a lot of pressure to get things out the door so the company can start making a buck. In my experience higher levels respond to 2 things, customer demand and regulators. Customers are being more vocal about security, and regulators are slowly waking up. Regulators can be scary though. Self regulation would be best but its unlikely higher ups will sign off on self regulation because its just going to cost them more time and money, and the reality is most corporates do not see software security as part of their core business. On Wed, Nov 26, 2008 at 4:26 AM, Mark Rockman <[EMAIL PROTECTED]> wrote: > It be difficult to determine a priori the settings for all the access > control lists and other security parameters that one must establish for CAS > to work. Perhaps a software assist would work according to the following > scenario. Run the program in the environment in which it will actually be > used. Assume minimal permissions. Each time the program would fail due to > violation of some permission, notate the event and plow on. Assuming this > is repeated for every use case, the resulting reports would be a very good > guide to how CAS settings should be established for production. Of course, > everytime the program is changed in any way, the process would have to be > repeated. > > MARK ROCKMAN > MDRSESCO LLC > ___ > 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] Language agnostic secure coding guidelines/standards?
Hi All Thank you for your replies, they have been very useful and will certainly help identifying things that need to appear in the standard. We're trying to make the standard something that is easily auditable, and have decided to further split items into two categories, those that should checked in development and those that should appear in the project documentation (e.g. things like definitions of log integrity/confidentiality requirements etc). I'm also happy to say that within our organisation we already have secure coding training available for developers, support channels for developers with queries, language specific guidance, automated tools that can be used to detect software flaws as well as an internal auditing and pentesting function. Needless to say it's been a big effort to get all this in place. The policy is an important piece of the puzzle which will hopefully help ensure the training and tools are utilised by developers. These things are all great, but from an organisational perspective one of the most important things for us is the ongoing risk management of identified issues. We have a lot of applications in various stages of development and production, and a lot of developers. Tracking known issues, remediation timelines, and who is responsible for what is also a very big part of it, especially in larger organisations. Again I'm happy to say we have an internally developed system for doing this. Rather than just giving myself a gold star on a mailing list, I would say to the vendors here interoperability is a big thing for us, as no one product does it all to the level we require (and it's unlikely they ever will). We are far more likely to buy things that play nicely with what we have already, and so far, most of the tools we use do. Gold stars all round. Anyway, thanks again for all the information. Cheers, Pete On Thu, Nov 20, 2008 at 8:00 AM, Gary McGraw <[EMAIL PROTECTED]> wrote: > badness-ometer-pedia! most excellent descriptive phrase. You guys should > change the official name! > > Incidentally, one of the best uses data like these can be put to is training. > > gem > > company www.cigital.com > podcast www.cigital.com/silverbullet > blog www.cigital.com/justiceleague > book www.swsec.com > > > On 11/17/08 4:49 PM, "Steven M. Christey" <[EMAIL PROTECTED]> wrote: > > > > The CWE Research view (CWE-1000) is language-neutral at its higher-level > nodes, and decomposes in some areas into language-specific constructs. > Early experience suggests that this view is not necessarily > developer-friendly, however, because it's not organized around the types > of concepts that developers typically think in. > > http://cwe.mitre.org/data/definitions/1000.html > > (click the Graph tab on the top right of the page to see the breakdown) > > Obviously the CWE is a badness-ometer-pedia but suggests some areas that > your guidelines would hopefully address. > > - 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. > ___ > > > ___ > 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] Language agnostic secure coding guidelines/standards?
Hi all I've been tasked with developing a secure coding standard for my employer. This will be a policy tool used to get developers to fix issues in their code after an audit, and also hopefully be of use to developers as they work to ensure they are compliant. The kicker is it needs to cover things ranging from cobol running on a mainframe, in house network monitoring software in c and perl through to web and desktop applications in java or .net. I've been doing some searching to see if there is anything similar online, but everything i've found is mostly focussed on web applications or language/platform specific. Does anyone know of something that may be what I'm looking for? It's basically going to be a checklist where every item will be something that can be audited, and the things that aren't relevant to a given application can be ignored. The broad sections I have so far are: Input/Output handling Session Control and Management Memory allocation and Management Authentication Management Authorisation Management Data Protection Logging and Auditing Application Errors and Exceptions Thanks in advance Pete ___ 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] darkreading: PCI, web app firewalls, and software security
Thanks for this, many interesting points. Many of them, such of quality of auditors and the vagueness of requirements/specifications are structural issues present in all industries that will never go away. There's never enough good people. If you're a shit hot accountant you're going to be off making millions at a hedge fund or an IB, not ticking the same boxes every other day in an audit. Similarly, if you're able to make intelligent decisions regarding ECB or CBC you're probably not going to enjoy spending your days checking companies keep their av definitions up to date. One of the problems with standards/policies/audits is it's easier to focus on adhering to policy or passing the audit than actually securing things. Especially if you're a corporate drone (and I say this as a corporate drone). Realising that policy is wrong, or standardised audits full of gaping holes, and actually getting people to do something about it is a difficult, messy, never-ending and usually thankless task (cause hey, if it was meant to be that way why wouldn't it say so in the policy?). It's a lot easier to ask if they want a blue or black pen used to check the boxes. Policy is useful to beat people over the head with after the event though, and even a token effort at PCI DSS compliance is going to be a good thing. > 9) The dirty little secret that no one is talking about are the operational >issues with WAF. Our company discussed possible use with WAF/XML firewalls >years before PCI DSS made it "popular". > >We never got much beyond initial discussions because we couldn't >identify any existing personnel within our company who had all the >required skills to troubleshoot it AND would be willing to do so. >(Think additional "pager duty".) We talked with stakeholders from >InfoSec, our company's network engineering team who manages our border >firewalls and routers, some *nix and Windows OS system administration >teams, and amongst our team. I think there might be only 2, possibly >3, people who have sufficient skills to operate and troubleshoot a >WAF, and all of those people are smart enough to know that it would be >a thankless job and they aren't really looking for additional opportunities >to carry pagers. Chances are, we would have to probably hire a few people >fully dedicated to this, but even then, there is the question where would >they fit organizationally? One possible option not explored--because we had >no stakeholders represented who could finance such a thing--would be to >outsource the management of WAF to some managed security company such >as BT Counterpane, ISS, etc. Anyhow, it's a big problem and one that >isn't going to go away. > >At first, intuition would suggest at first that usual FW teams would be > best >suited (and that indeed is what most WAF vendors suggest), but for the most >part, the usual FW teams' understanding of attacks at layer 7 is often >very limited. > >If you or anyone you know ever comes up with a solution on how to address >this particular issue, please let me know. I think it is a show stopper. > IMO the FW team is where it should be. If you have otherwise competent FW people, they should be able to pick it up. If PCI is a standard there's going to be a lot of companies requiring WAF expertise, so you would hope the existing team would be open to learning a new, desirable skillset/technology. At my company we have a 24x7 global/follow the sun IDS monitoring team, and it would probably fall to them. As I see it, you either implement a boilerplate PCI DSS compliant policy from your vendor, or hire a consultant to help come up with a policy that agrees with your company policy as well as PCI DSS. Infastructure project to implement it, then pass it off to the FW/IDS team for monitoring. Like you say in 1) 99% of the PCI DSS is what any good IT organization should be doing already. The cost to reach PCI compliance shouldn't be to excessive, but I wonder if it would be cheaper to start your own PCI auditing company ;-) ___ 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 Software Costs US $180B per Year - Application and Perimeter Security News Analysis - Dark Reading
On Dec 3, 2007 8:34 AM, silky <[EMAIL PROTECTED]> wrote: > > how does anyone know how to hire anyone for a job that they themselves > aren't qualified for? well, you pay professionals to do it. > recruitment agents. this should be part of their role. and absolutely > agreed; most certification is useless, secure programming is no > different. > > Um, have you ever dealt with a recruitment agent? How are they going to tell? The guy had secure coding on his CV? Ok A few points in general: 1 - I'm yet to meet a programmer who intentionally creates security problems in production code. Most developers I meet are very much interested in secure coding, so in that respect things are a lot better than they were 5 years ago when very few people knew, and even less cared. Penalizing developers for writing insecure code is not the answer, because as others have pointed out all it will do is encourage people to cover things up and never talk about security vulnerabilities. You have to take into account the environment in which they work, which is most likely not conductive to producing quality output, and also that even the best people will make mistakes. I've heard of some companies taking the attitude that code level security issues are OK, because it means they didn't waste too much money on higher quality outsourced developers ... and from a security vendor no less, whoda thunk ;-) 2 - Source code scanners still have a long way to go. I realize there are a lot of vested interests on this list, but based on my recent experiences with commercial scanners it is pure folly relying on them to secure your applications. They are useful tools with a real place, and better than previous generations, but overpriced and still of limited value. That they are sold as "quality tools" rather than "security tools" is telling. Running code through 3 different scanners is great, but a) who has the time, b) who can justify 3 different tools to management, c) who's going to wield the rod, and d) why do you think anyone would actually care about the rod? 3 - Taxes, government bodies, penalties, etc. all bullshit for now. When its possible to prove a program is correct, ok, but until then its way to fuzzy and wobbly to start throwing bureaucracy at. It would be good to see some form of self-regulation, ideally from a credible independent source, not a cert merchant or security services vendor. Yours in brevity, Pete ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. ___
Re: [SC-L] Vulnerability tallies surged in 2006 | The Register
This strikes me as largely meaningless, bordering on good news. More bugs found = more bugs fixed = more secure software. I dont really think you can compare the numbers from 2001 and 2006 though. There's way more people looking for bugs now than there were in 2001. Maybe there were more bugs around in 2001 as secure coding practises still weren't well known, and security was nowhere as mainstream as it is now, so your average developer was less aware of secure coding practises and techniques. Also, nowadays people rush to disclose vulnerabilites, no matter how minor they may be. There were plenty of vulnerabilites discovered in 2001 that weren't publicly disclosed, and some that probably still remain undisclosed. I would be interested to see what conclusions you can actually draw from these figures (really). On 1/23/07, Kenneth Van Wyk <[EMAIL PROTECTED]> wrote: > > FYI, CERT/CC reported 8064 software vulnerabilities in 2006, for a 35% > increase over 2005. > > See > http://www.theregister.co.uk/2007/01/21/2006_vulns_tally/ > > The article further states, "The greatest factor in the skyrocketing number > of vulnerabilities is that certain types of flaws in community and > commercial Web applications have become much easier to find, said Art > Manion, vulnerability team lead for the CERT Coordination Center. > > 'The best we can figure, most of the growth is due to fairly > easy-to-discover vulnerabilities in Web applications," Manion said. "They > are easy to find, easy to create, and easy to deploy.'" > > Cheers, > > Ken > - > Kenneth R. van Wyk > SC-L Moderator > KRvW Associates, LLC > http://www.KRvW.com > > > > > > ___ > Secure Coding mailing list (SC-L) SC-L@securecoding.org > List information, subscriptions, etc - > http://krvw.com/mailman/listinfo/sc-l > List charter available at - > http://www.securecoding.org/list/charter.php > SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) > as a free, non-commercial service to the software security community. > ___ > > > > ___ 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] re-writing college books - erm.. ahm...
On 11/7/06, Wall, Kevin <[EMAIL PROTECTED]> wrote: > > Developers have to cut corners somewhere, and since security issues > are not paramount, that's often what gets overlooked. > this is the biggest issue i think. it gets overlooked because management dont value it. partly because its expensive to do, and theres no real qualitative or quantitative measures of success. you cant go to your management and say "i spent 20% of my time working on security issues, it cost us $x but it will save our customers $y, and security was improved by 15%" or if you can, you're bullshitting, but will probably get a nice bonus :) i think a college level textbook would have limited benefit. there is plenty of information out there at the moment for those who are interested, both on the net and in book form. i suppose its nice to have a single point of reference though. however, most graduates aren't really good practical programmers. they know stuff like what a for loop is and how recursion works, which is great, but they learn the ins and outs of developing when they get their first real job. so they get their first job, and basically learn from the people they're working with. the people they're working with and learning from are busy, and working under time and budget constraints. they're just not going to focus on security, even if they had the knowledge to do it effectively, because other things are more important to the companies management. most managers (and developers too i guess) do care about security, but only in the way people care about global warming. they know global warming is bad, but oh gee what are we going to do, oh today i remembered to turn off my desk lamp when i left the office. great. same with security, you dont have to be a genius to work out security holes are bad, but oh gee what are you actually going to do about it? if organisations dont really care about software security, a security concious developer faces an uphill battle. if two devs are working on some code, one does it slower but more securely, the other does it quicker but less securely, who's going to look better, in a typical organisation? your fresh grad is going to learn quick enough what companies want from them. as time goes by, they become the ones breaking in the new developers, so the cycle continues. a book isnt going to help this, it probably wont hurt, but i dont think the lack of available literature is a big problem. a good organisation will focus on what its customers want. untill the customers start kicking up a storm about vulnerabilities, there's little impetus for management to devote resources to security. i think this is one of the things microsoft has done well, over the last few years they have started taking security seriously, and i can only assume its because their customers starting complaining. they still have a lot of security issues (an insuperable amount imo), but it shows that for companies to start taking software security seriously, it has to be something the customer wants. ___ 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
