Building bridges between Software Development and App Sec

2. Building secure software is hard Development has to take ownership for writing secure code Developers need help to do this – from the security community But there are serious gaps between Dev and AppSec How can we bridge these gaps? The Problem SANS AppSec 2011 (Mar 7/11) Building Real Software

3. 20+ years in software development and managing development teams Specialist in financial trading platforms for exchanges and investment banks I manage small teams with big customers I want to find better ways for small teams to build good, reliable, secure software Blog in my spare time about the challenges that small teams face building real software SANS AppSec 2011 (Mar 7/11) Building Real Software Why I’m Here

4. Priority Gap Features Cost/Time to Market Connectivity and Integration If we succeed: performance, reliability, compliance, … Security? Knowledge Gap Language Gap XSRF, reflected/persistent XSS, XST, XSSI, 0-day exploit, XPath injection, pwning, session hijacking, SQL smuggling… attacks and hacker-talk Quality Gap – the Attacker’s Advantage Ownership Gap and Capability Gap SANS AppSec 2011 (Mar 7/11) Building Real Software The Gaps

5. SANS AppSec 2011 (Mar 7/11) Building Real Software Independent Communities

6. Education and awareness: developers can’t prevent or fix what they don’t understand OWASP 2011 Summit: “Developers don’t know shit about security” Break security problems down Pragmatic practices: fast, simple, work under pressure – for small Agile teams Make it harder to write bad code SANS AppSec 2011 (Mar 7/11) Building Real Software AppSec has to be Simpler

7. It’s too easy to make security mistakes Frameworks and languages aren’t secure Instead of lists of do this, don’t do that: Ivan Ristic: “Design platforms, libraries and components in such a way that vulnerabilities cannot exist. Then use them.” Better tools to find problems in legacy code Too many dups, too many FPs, too many FNs Too expensive – to license, to get working We need a stronger Open Source community WAFs aren’t the answer either Nothing is good enough, today… SANS AppSec 2011 (Mar 7/11) Building Real Software We need better tools

8. “Soft” problems - developers Data validation Exceptions and error handling Race conditions, locking, concurrency Bad coding, stupid mistakes: overflows, null pointers, leaks, arithmetic errors, debugging code.. Good layered architecture “Hard” problems – security experts Secure design: authentication, authorization, …. Crypto and secure protocols Technology-specific security problems, research… SANS AppSec 2011 (Mar 7/11) Building Real Software Software Security is 50/50

9. SANS AppSec 2011 (Mar 7/11) Building Real Software Who Owns the Security Problem?

10. Developers aren’t victims We can and should own problems But we need help… from AppSec We have to bridge the gaps Like Dev and QA communities 10+ years ago Independent test groups, walls and gates Better results from opposed interests – objective Expensive tools, manual testing, checklists XP and Agile changed all this SANS AppSec 2011 (Mar 7/11) Building Real Software Taking Ownership Together

11. Look at DevOps Community leaders taking on problems together Writing better tools and using them Hold conferences together: Velocity… Lightweight, practical, collaborative – every level OWASP Developer Outreach OWASP is trying to connect with developers Builders and Defenders communities SANS AppSec 2011 (Mar 7/11) Building Real Software Building Bridges

Hinweis der Redaktion

We have a lot of problems to solve. They can’t call be solved from inside, or from outside. Developers need to understand what it takes to write secure software, and take ownership for writing secure software. And by “developers” I don’t mean just the programmers. I mean everyone involved: project managers and development managers and Scrum Managers and test engineers and product managers and business analysts and… We need help to do this. We need help to understand the problems. And help breaking them down into problems that can be solved. We need to make it harder for developers to write bad software. We need help from the security community. But we live in different worlds – our interests and approaches are often in conflict. We need to change this.
What is important to developers: #1 features, business value… #2 a balance, a trade-off between time to market and cost #3 getting customers and partners hooked upAnd all of that technical stuff that the business expects us to do because we are professionals and that it is what they are paying us for. What’s important to me as a development manager is to find ways to streamline work and deliver faster, to find new technologies that will open up new channels and opportunities, to improve performance and stability and reduce the cost of operations.These aren’t the same priorities as the security community. We need to find the overlap here. Knowledge – developers don’t know enough to know what they are doing wrong and what they should do instead. This is changing, conferences like this are helping, but it is taking a long time.We speak different languages. What is SQL smuggling anyways? I am not even sure how to pronounce pwning.And we have to deal with a serious quality gap. Most developers build “good enough” software – or try to. But how good does it have to be, to be secure? How secure is “secure enough”? You find out quickly enough when you have messed up a functional requirement, or you have a performance problem or a reliability problem in production. But you don’t always know, may never know, what security problems you have.Ownership: Developers look at security like it is somebody else’s problem. And finally, we run into a gap between the problem and our ability to respond to it. Developers don’t have enough money or time to deal with everything. Appsec doesn’t have enough money or time. Both are stretched too thin.
Developers and appsec live in independent, isolated and self-reinforcing communities: the books that we read, the conferences that we go to, the people who we look up to, what we spend our spare time learning, what’s important to our careers.Go to software development conferences. Read software development books and blogs. What are they about? Delivery. How to build and deliver good software. If we don’t deliver, we fail. Better, cheaper, faster. By better, we mean more feature rich, more open, more extensible, more intuitive.What are we looking for?New languages, dynamic languages and functional programming. New frameworks and toolkits. Simpler ways to build cool software. Better ways to work. Agile development, Lean and Kanban, continuous risk management, leadership and coaching, managing distributed and offshore teams, TDD and ATDD and BDD, refactoring, continuous integration, continuous delivery, continuous deployment…. How to create mobile apps and Web 2.0 goodies, and integrating social networks to build communities.These are some of the books that software developers and managers read, or should read, about building software. These are brilliant books. Written by brilliant people. They are about how to do the best possible job managing software development, writing and testing code. And they have nothing to say about software security. Not a thing. Code Complete for exampleis the bible on how to write code. It has hundreds of pages on how to write and maintain code responsibly. Steve McConnell admits that it doesn’t touch on security. Even these people, some of the smartest and most passionate in the dev community, don’t deal with the problems of software security.
The software community is attention-deficit. There’s always a new new thing, a shiny new and better language or methodology or architectural pattern or framework or whatever to chase after that will make software development better this time really. And at the same time bad guys aren’t staying still, they are finding new ways to exploit mistakes and bad design. I am not sure that software security can keep up. So we have to break the problems down, make them clearer and simpler and get more people working on them.Don’t make secure software a security problem. Make secure design problems a design problem.Make secure coding problems a coding problem.Make secure testing problems a testing problem.Make secure software management problems a management problem.And make the people responsible for those problems responsible for solving them.We need simple practices and simple tools that fit the way that people are trying to build software today. Incremental, simple, lightweight, automated.
Conferences like this are important. We have to educate developers. They have to understand what things are dangerous, when they are doing stupid things – because with today’s technology it is far too easy to do stupid and dangerous things. And it’s too hard and expensive and time-consuming to find out what mistakes we have made, and how serious they are. Security tools today kinda suck – too many dups and false positives, not enough real findings, most of them cost too much and take a lot of work to setup and more work to understand the results, and what to do with the results. You need help from consultants to use them, to understand how they work, to understand what they find, and what really needs to be fixed or changed and how to do this safely.Static analysis only finds a subset of problems, and takes work to setup and to properly configure, to “train” the tool for your application. Web vulnerability scanners also take time to setup and train and to understand the results, and they only find some instances of some problems. You can (and should) try fuzzzing, but that’s another pain in the ass to setup and run and work through, and fuzzing will only help find some problems (data validation and error handling).After all this you still don’t know how secure you are (although you may know how secure you aren’t). So you need a manual expert code review and manual design review, and manual pen testing. You may want to put in a Web Application Firewall, but you will have to find one and set it up and tune it and train it, and keep it up to date, and, you guessed it, it will only protect you from some problems. This doesn’t scale – up to the high end or down to the low end. For the enterprise it takes too long and costs too much. And it’s insane to expect small companies to spend this much time and take on all of this work and these costs.
Gary McGraw at Cigital breaks software security problems down into two kinds of problems. One half of problems are coding bugs. The other half are design flaws. I like to think of these security problems as soft problems and hard problems. Soft problems. 50% (or more) security problems are caused by writing bad code, making fundamental mistakes in implementation, and by messing up simple, fundamental design and architecture decisions around layering and handling of private data.Look a the Mitre’s CWE (Common Weakness Enumeration), the catalog of problems in software that cause serious security violations and reliability failures. Page after page of dumb-ass mistakes, all that come with serious consequences.If you get your team trained on secure programming, they are going to spend about half of the time learning about real security problems, and the other half reviewing defensive coding and basic code quality problems. Good programmers should know this stuff already, technical managers can understand it, it’s almost all good fundamental technical practices and good design.Then you have the other 50% of security problems. Hard Security problems – because they are hard to understand and harder to solve if you don’t know what you are doing. These are security requirements and design problems, and specialist technical stuff, the dark arts.Crypto – although the most common crypto problem is not encrypting something that should be encrypted, which is not exactly a “hard” problemAuthorization: simple business rules which everyone gets wrong – every multiuser system needs it, why do we have to keep doing this over and overBasic password management - dittoSecure session management and secure protocolsRecognizing and dealing with attacksPlatform hardening and secure configuration (CIS)Technology-specific and language-specific security weaknesses and security quirksSecure APIsResearch and exploitsForensicsPen testing and ethical hackingFixing the Internet – browser weaknesses and TCP/IP problems and….Helping developers to use existing appsec toolsMost programmers aren’t going to write secure authentication protocols or take care of encryption or deal with some of these hard problems – or know how to. But they are going to spend a lot of time writing customer-facing and Internet-facing code.So – get people to write better software, and we’re half way there…. Let’s start with doing a better job of writing code, and taking care of the code that we have already written. Let’s find the overlap between security and quality – it’s an easy case to make.Software Security is not Software Quality. I understand and agree. But… you can’t be secure if the software is not reliable, high qualityAnderson: Security Engineering“It has been shown that investments in software quality will reduce the incidence of computer security problems, regardless of whether security was a target of the quality program or not.”
Software security is a problem.It’s not INFOSEC’s problem. It’s not compliance’s problem. It’s not network engineering and Ops. It’s not somebody else’s problem – or nobody’s problem. It’s everybody’s problem, and it needs to be solved by everybody working together.
Security can’t be solved without developers – at least not until Dr. Chenxi Wang’s vision of self-securing software comes true. So developers have to take responsibility for building secure software. That’s what this conference is about.How do we go about doing this?I am going to back and reinterpret history for an answer.More than 10 years ago there was a serious gap between the development community and the testing community. Designers designed, then gave specs to programmers to program. Programmers programmed and threw the results over a wall. Testers tested then tossed the results back in frustration. Putting in structure and controls like CMMI and ISO 9001 didn’t help, mostly it drove up the costs and stakes. Projects were taking too long, costing too much, and too many of them were failing.I managed organizations and teams that worked this way. I was taught that we would get better results from developers and testers working independently and in opposition. That we would find more problems, more effectively this way. And it didn’t work.Some smart people recognized that this wasn’t going anywhere fast, that there were some serious problems that needed to be solved. So they got together and looked at the problems that the industry were facing with large-scale software development projects, why projects failed. And came up with ways to build software faster cheaper and better, with less upfront planning and paperwork and more emphasis on the real job of building software. And they realized that if you are going to spend less time upfront planning and fussing around and more of your time actually coding, you need to make sure that you write good code, and that you are able to change it easily and safely. Out of this came better coding practices, automated developer testing, continuous integration, refactoring and other disciplines like pair programming. Testing your own code became cool, and then it became accepted, and now it’s become expected. We still need test engineers, but now they can do much more than manual acceptance and regression testing.The gap hasn’t been bridged completely, not everywhere. But the situation has changed a lot for the better. And we make better software because of it.
People have to see problems themselves and then want to solve them. Look at DevOps. A small group of smart and serious people trying to come up with a new way for system operations and developers to work together to solve application operations problems at massive scale. They are doing this in an open, simple, collaborative and exploratory way, focusing on problems and sharing solutions.DevOps has momentum, I can see that it is already making a difference. People are learning about new ideas and new tools, and getting smarter. The reason: because these people are leaders in the operations community. They’re living the dream-scratch-nightmare. They have street cred. But it’s much more than that. They are solving real problems, problems that are important to them. And in their own ways. They understand what’s wrong, and they’re coming together to find answers. They are sharing what they are doing, sharing ideas and code and success stories. It’s about being practical, about people getting together, breaking down walls, solving problems. It’s involving, not alienating.I think that both development and system operations for online systems and enterprise systems are going to be the better for it.We have to do the same thing for security.We have to engage the leaders of the software development community, the people who write the books and blogs and teach the courses, and shape what developers and testers learn and think about, what we think is important. Explain the problems and risks, make sure that they understand what is important, and convince them to get engaged.So when people talk about and think about and write about and teach coding, they talk about and think about and write about and teach how to do it in a secure way. And when people talk about and think about and write about and teach Scrum, and Kanban, and Continuous Deployment and whatever other ideas they come up with to improve how software is built and delivered, they make sure that it can be done with security in mind. Appsec needs to help the people who build frameworks and open source tools and libraries, and who design the programming languages that we use. So that security is anticipated in the way that we write code. So that developers don’t have to worry about plugging all of the stupid holes in how the web works. So that the tools that we use are secure by default.And we need developers to go to software security conferences like this. And security people to go to software conferences, and hold appsec tracks – like this year’s NFJS Uber Conf in July.And developers need security answers and resources, examples and patterns: in books, in blogs, in stackoverflow and other forums.Security has to be burned in from the bottom up and the top down, all the time, at every level. OWASP has just launched a Developer Outreach initiative, to explore ways that developers (builder community) and appsec (defender community) can work together, find better ways to do security testing, and so on. There are mailing lists and google groups setup, there’s some blogging. It’s too soon to know where it will go or if it has staying power. But it shows that people are trying.