tag:blogger.com,1999:blog-5028009537158799436.post7361636695259179682..comments2023-07-10T04:50:03.236-07:00Comments on Building Real Software: Developers just don’t go to security conferencesJim Birdhttp://www.blogger.com/profile/17371102366836131341noreply@blogger.comBlogger13125tag:blogger.com,1999:blog-5028009537158799436.post-83571769276524520822010-12-07T02:25:07.264-08:002010-12-07T02:25:07.264-08:00I think that we'll have our own conferences, w...I think that we'll have our own conferences, which may look a lot like Cigital's.software application testinghttp://www.neosofttech.com/application_migration.htmnoreply@blogger.comtag:blogger.com,1999:blog-5028009537158799436.post-57692169860423786872010-09-08T04:43:14.578-07:002010-09-08T04:43:14.578-07:00Hi Jim,
I talk to a lot of developers about secur...Hi Jim,<br /><br />I talk to a lot of developers about security. A few 'get it' but most know that they dont know enough.<br />They see penetration testing as a 'black art' that is only practised by l33t haxors.<br />I dont think theres any one solution to this, although decent training would be a good start!<br />However I also think theres a case for teaching basic pen test techniques to developers and functional testers. It wont be for everyone, but the devs I've taught have all said that it really opened their eyes.<br /><br />Now for the blatant self promotion :)<br />I've just released a pen test tool explicitly aimed at developers - the Zed Attack Proxy (ZAP): http://code.google.com/p/zaproxy/ (its a fork of Paros) and also started a blog: http://pentest4devs.blogspot.com/<br />Not a great deal to see on there yet but any feedback on ZAP or the blog will be appreciated.<br /><br />PsiinonSimon Bennettshttps://www.blogger.com/profile/04432171854745527524noreply@blogger.comtag:blogger.com,1999:blog-5028009537158799436.post-89182226196985502432010-08-13T11:32:11.499-07:002010-08-13T11:32:11.499-07:00Quality Assurance makes sure the project will be c...Quality Assurance makes sure the project will be completed based on the previously agreed specifications, standards and functionality required without defects and possible problems.<br />And for that the software developers have to take a help from the software testing tool.<br />-<a href="http://www.proprofs.com/quiz-school/" rel="nofollow">quiz software</a>johnsonhttps://www.blogger.com/profile/06965798407799844038noreply@blogger.comtag:blogger.com,1999:blog-5028009537158799436.post-86186131612988857372010-07-30T10:26:48.830-07:002010-07-30T10:26:48.830-07:00Hey Jim,
I think that's fair. A couple of po...Hey Jim,<br /><br />I think that's fair. A couple of points to add if I may. <br /><br />Firstly, the security requirements in certain domains is clearly more critical than others. Obviously in your domain, it is as critical if not more than any functional requirement. I've spend some time in the upstream O&G space, and I'll tell you, it's far from that. I a consumer, I don't want to pay for the Caddy if the Pento will do. I just need to understand what I'm buying.<br /><br />Secondly, I distinguish the 'developer' role as someone who doesn't necessarily educate the customer. I do agree with your statement 'professionals who know how to do their jobs', I just don't think it's necessarily their job. If you invest in a system, you need to understand what you're investing in. Take some initiative as a customer to understand what security means to you. It's not different than any other kind of investment. Remember what Warren Buffet say's - "I don't invest in anything I don't understand". It's done well for him. :-)<br /><br />In the end, security is about risk mitigation. I agree that we need to do a better job educating.Andy Czerwonkahttps://www.blogger.com/profile/12753674450928055886noreply@blogger.comtag:blogger.com,1999:blog-5028009537158799436.post-11380506033541357672010-07-30T08:52:12.195-07:002010-07-30T08:52:12.195-07:00Hey Andy,
It's good to hear from you. I don&#...Hey Andy,<br /><br />It's good to hear from you. I don't see the lack of focus on software security as a failure of the business or the customer so much. The customer asks us as professionals to build them a system: they expect us to know how to do our jobs, to write software that works and is reliable, and they expect us to follow good practices. And this includes understanding and following secure software development. I haven't worked for a customer who has told me not to build a system properly: they expect me to. Of course, they may not be willing to pay enough for it, and as long as it is clear to everyone involved what compromises will need to be made to save costs, what the risks are, then that is a business issue that can be managed. Not every system needs to be secure.<br /><br />The way I see it, the bigger problem is with the people who manage software development: CTOs, development managers, project managers, Scrum Masters, lead developers and architects, and the consultants who help us understand how to build software. Most of these people don't understand what is involved in building secure and reliable software, and it is not a priority for them. They are the ones who decide or influence where to spend time and money, what tools to use, what training people are going to get. <br /><br />Building software to be secure needs to be as important and as second nature as building it faster and with less risk. And I don't think that this will happen without the involvement of the leaders of the development community, without them understanding the problems and including software security in the way that we build software.Jim Birdhttps://www.blogger.com/profile/17371102366836131341noreply@blogger.comtag:blogger.com,1999:blog-5028009537158799436.post-42688238080113880272010-07-29T07:57:16.784-07:002010-07-29T07:57:16.784-07:00Hey Jim,
I'm not sure it's the developers...Hey Jim,<br /><br />I'm not sure it's the developers. In my experience anyway, it's the business that doesn't get it. And if they don't 'get it', then they're naturally not willing to invest in it because they don't see the value.Andy Czerwonkahttps://www.blogger.com/profile/12753674450928055886noreply@blogger.comtag:blogger.com,1999:blog-5028009537158799436.post-48765298280737160712010-07-14T09:48:09.446-07:002010-07-14T09:48:09.446-07:00Some software developers do "get it". M...Some software developers do "get it". Most do not. Those that do understand the need and the principles involved usually do not have the time to spend on it that is required.<br /><br />I taught input validation to everyone on the development team a couple years ago. Yet, every single time I do a code review, I find missing input validation.<br /><br />The same developers (who are fairly competent) make similar mistakes over and over again. The security mindset just does not seem to be present - no matter how many times they end up rewriting something.<br /><br />I am not sure how to overcome that. It largely seems like many developers just don't care. They will bolt security on after they are done.<br /><br />I have reviewed code from other organizations where they incorporate security in the software development life cycle and found similar issues. <br /><br />I think the security aspects of software development need to be more integrated into the VERY early stages of learning to program. Seems almost like you can't teach an old dog new tricks. So, once the developers have learned to develop, they can't seem to change how they develop.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-5028009537158799436.post-65198410554533671032010-07-14T02:26:17.696-07:002010-07-14T02:26:17.696-07:00The problem I frequently see and hear is that secu...The problem I frequently see and hear is that security testing is a phase that is outsourced to "experts", is expensive, and is thus left to the end of the delivery process. I often see emails from people bemoaning the fact that designing and testing for security can't be built in to the delivery process in the same way as capacity and availability can (although even this is a relatively recent phenomenon).<br /><br />Until there are tools and organizations that can make security testing a mainly automated process that can be run on demand (with experts creating and managing the strategy and monitoring its effectiveness, of course), it's not going to become integrated into the delivery process.<br /><br />Yes, that means developers working to create the tools and practices that allow this. But it also means security experts working with developers to create these tools and processes.<br /><br />My perception - which is admittedly not based on a lot of experience - is that many security experts treat their approach as magic, special secret sauce that only they can provide, at great expense.<br /><br />I would love to be proved wrong - and I would love to learn more about how security can be baked in to the delivery process.<br /><br />Thanks,<br /><br />Jez.Jez Humblehttp://continuousdelivery.com/noreply@blogger.comtag:blogger.com,1999:blog-5028009537158799436.post-46030367977082557702010-07-13T18:35:27.815-07:002010-07-13T18:35:27.815-07:00It’s not passive attempts to “infect” development ...<i> It’s not passive attempts to “infect” development managers with vague ideas about being "Rugged" that are supposed to somehow change how developers build software. <br />The solution is to make secure software development a problem for software developers, a problem that we need to solve ourselves. Engage leaders in the wider software development community</i><br /><br />All the energy spent being critical of the fledgling Rugged Software project would be better spent participating and making it better. You make a point that the development team and its leaders need to be the target of the influence. This is in enthusiastic agreement with the Rugged philosophy. Can't we all just get along?Marisa Faganhttps://www.blogger.com/profile/01185065599379609480noreply@blogger.comtag:blogger.com,1999:blog-5028009537158799436.post-54037836597394014732010-07-13T18:20:35.638-07:002010-07-13T18:20:35.638-07:00I agree completely with dre. Good concept "bu...I agree completely with dre. Good concept "bug-fixer". Currently bug hunters are happy to show how stupid developers are, then let the same developers fix the bugs to then laugh again when they fix them incorrectly, they don't take any responsibility they just enjoy breaking the software and showing it in the face of developers and feeling smarter than them. But at the same time they never program, they could but they are afraid of making the same mistakes and loosing their reputation of cool smarter than you hackers. Anyway we have to accept that many bug hunters are brilliant, 10x more creative than an average developer. But what the industry needs is a merge between both. OWASP wont solve this problem exactly for the reasons that dre pointed out. Look at the software produced by OWASP is as buggy as any other software or even more, they are good at organizing events and promoting their organization but I haven't seen any good result from them. A secure implementation of common libraries? no, just mediocre broken code. Good guidelines? no, very incomplete. For me OWASP is good just for a few guys behind it and consulting companies trying to sell services. Hyping xxjacking attacks that a 12 year old can find and exploit better.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-5028009537158799436.post-56841095970026437432010-07-13T17:37:22.886-07:002010-07-13T17:37:22.886-07:00If these Software Developer gurus haven't gott...<i>If these Software Developer gurus haven't gotten it by now, I doubt they ever will. Most of them formed their outlook back when the network was trusted (if not before the network)</i><br /><br />Fortunately, the network is going away, or at least the concept of infrastructure containing both net and apps is going away with the rise of cloud computing.<br /><br />There Jericho Forum predicted the end to the DMZ concept, and I am going to have to agree with much of their premises.<br /><br />What we have now is metastructure (BGP, DNS, routing, switching, virtual networks -- shit that I don't care about anymore and know a lot about) vs. infostructure (apps and data). Most people no longer need to care about metastructure.<br /><br /><i>Most security conferences are open and the knowledge is generally available to whomever wants to learn it. Asking them for "help" is unlikely to be productive</i><br /><br />I disagree. I think that developers go to security conferences, but these conferences are still full of network-centric and WiFi-centric attack information. Application security has not yet hit it's prime in terms of maturity nor popularity.<br /><br />I also think that we need to raise awareness to software security issues everywhere -- all of the time.<br /><br /><i>Until such time as their "ship the prototype in 21 days" methodologies are recognized for what they are, we will have researchers presenting at security conferences informing the marketplace about which development shops can and can't do security</i><br /><br />I don't feel that 2-4 week sprints counter the need or capability of application security. It is the awareness, understanding, co-operation, agreement, and integration of application security into the application lifecycle management processes that must be accomplished. How about a hardening sprint before the prototype goes live?<br /><br />Did you know that prototyping (according to McConnell 740) is the best way to find and fix bugs? Well, I think it is also the best way to find and fix security bugs. It just must be integrated.<br /><br /><i>But I have a lot of sympathy for the individual developers who would love to be more engaged but have employers that don't see the cost-benefit</i><br /><br />Almost all of the app developers that I have met over the past 7 years who have an interest in appsec are now working in appsec. Why? Because it's exciting. Because they love it. A lot of them said that because of the problems/drama in the information security industry overall that they would leave (or take breaks from) appsec and return to doing software engineering/architecture full-time. Most of the appdevs who said that are now full entrenched in appsec again and promised to never return back.<br /><br />However, I understand the issues with the drama in infosec. Breach notification laws are a joke. PCI DSS makes Visa more money and does absolutely nothing to protect cardholders or make their lives safer from credential or payment card data theft. HIPAA is now officially the largest running joke the regulatory world has ever known.<br /><br />Jim Bird bolded a Computerworld article on "Hold vendors liable for buggy software, group says" in this blog post, specifically mentioning that this strategy would never work. I am not as convinced that it will not. Without legislation, companies will profit massively in the short-term (much to the expense and chagrin of consumers). However, in the long-term, legislation will favor many small companies and consumers and the eventual trend will be that software products mentioned in popular lawsuits will tend to get more application security rigor around them. Wait and see; I bet I'm right here.<br /><br />It's either legislation or litigation, folks.drehttps://www.blogger.com/profile/17414510788948258195noreply@blogger.comtag:blogger.com,1999:blog-5028009537158799436.post-38470837288507421722010-07-13T17:02:32.834-07:002010-07-13T17:02:32.834-07:00If these Software Developer gurus haven't gott...If these Software Developer gurus haven't gotten it by now, I doubt they ever will. Most of them formed their outlook back when the network was trusted (if not before the network).<br /><br />Most security conferences are open and the knowledge is generally available to whomever wants to learn it. Asking them for "help" is unlikely to be productive.<br /> <br />Until such time as their "ship the prototype in 21 days" methodologies are recognized for what they are, we will have researchers presenting at security conferences informing the marketplace about which development shops can and can't do security.<br /><br />But I have a lot of sympathy for the individual developers who would love to be more engaged but have employers that don't see the cost/benefit.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-5028009537158799436.post-55942061599456703262010-07-13T14:57:33.553-07:002010-07-13T14:57:33.553-07:00Gunnar Peter and Jeff Williams made an attempt at ...Gunnar Peter and Jeff Williams made an attempt at the QCon conference (InfoQ) a few years ago. I occasionally see appsec-savvy Microsoft developers teaching software security at MSDN conferences or via outlets like Pluralsight. Sometimes you'll find people like me trying to talk about the dev-test side of software security at hacker conferences.<br /><br />A bridge has been built in many organizations between development and quality-assurance. Many waterfall SQEs left the typical QA groups to join development as "dev-testers". The role of the SQE, at least in a lot of Agile environments, has been reborn.<br /><br />Security testers and penetration-testers need to be reborn as well. Instead of identifying issues that affect quality, we must rely on the work already done by dev-testers and interface directly with them, their methods, their test harnesses, their automation methods, their manual methods and tools. Then, we must simply "fix the security bugs" and usually do so while "nobody is looking". I envision this role as the security-bugfixer and have been discussing it for quite some time now. The point is that someone is paid to fix the security bugs as they come along (because nobody else is going to do it).<br /><br />Until we can get to "security-bugfixers", we will have the current role: security advisors (http://mikeboberski.blogspot.com/2010/07/what-im-up-to-these-days.html) aka the "security buddy". This person works on `building security in' to the entire lifecycle. In my opinion, avoiding classic SDLC models and even the Microsoft SDL is preferred. I think that security advisors should work with the new ALM development paradigm -- but we've discussed application lifecycle management in the past.<br /><br />I tend to think that we'll have our own conferences, which may look a lot like Cigital's verifyconference.com. A lot of these efforts to combine quality and security testers have failed. Perhaps OWASP AppSec is the right place for them for now -- but I dislike that people adverse to this cause, such as Jeremiah Grossman and RSnake -- get invited.<br /><br />Even at the OWASP conferences, penetration-testing's popularity and the rockstar personas surrounding them permeate and pervert the con. I would assume that this has something to do with fame and fortune: two things that the hacker community cannot seem to let go.drehttps://www.blogger.com/profile/17414510788948258195noreply@blogger.com